I know this is an unstable kernel, but I just wanted to let people know of
my experiences with SDL and ALSA in the latest test kernel.
If I use SDL_AUDIODRIVER=alsa, then games (both compiled and binary) and
other applications become very choppy, and the framerate becomes choppy
as well.
At first I thought it was because of the new scheduler changes, and that
the application was hogging the CPU and causing the scheduler to swap out
the app every now and then. But when I tried SDL_AUDIODRIVER=dma, then
it worked fine.
I just happened to have an application that could test various sound
backends, which is the Atari emulator Stella that I’m working on. The
emulator can use 3 different sound backends and 2 modes of time
synchronization.
Specifically, if I use busy-waits (98% CPU used) and audio is OSS or ALSA
directly, there is some occasional popping, but no choppiness. If I use
non-busy-waits (1% CPU used) with OSS or ALSA, there is no popping at
all.
Now, if I use the SDL audio with the ALSA backend, whether busy-wait or
not, the sound and video is very choppy and skips a lot. But when the
SDL audio uses DMA, everything is fine again.
I don’t know exactly what the problem is, and I’m actively researching it.
But it seems odd that it only happens when SDL uses ALSA, and not when
a program uses the ALSA API directly.
FYI, when DMA is used, it uses the OSS emulation in ALSA, so ALSA is still
being used, just with a different API.
I will be trying different versions of SDL, ALSA, and test kernels, and
I’ll let you know what I find out.
Steve