Constant buffer underruns when using plain ALSA audio (native SDL2 worked fine)

[vanfanel]

Hi there,

Using plain ALSA audio, I get constant buffer underruns when running SDL2 games using SDL2-compat instead of "native" SDL2.

For example, with SDLPop (https://github.com/NagyD/SDLPoP) I get this constantly and audio is constantly cut off:

manuel@debian:~/prince$ prince.exe
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred

IMPORTANT

• It does not happen with native SDL2 as I said.
• It does not happen when using pipewire audio instead of plain ALSA audio.

MORE INFO

I think something is still off with SDL2-compat when plain ALSA audio is used, probably related to period/buffer sizes since mangling with /etc/asound.conf I can get it somewhat working.

I usually have this on /etc/asound.conf to simply have my direct hardware output (DP-1) selected:

pcm.!default {
        type hw
        card Generic
        device 8
}

ctl.!default {
        type hw
        card Generic
}

...and that works fine with native SDL2, but with SDL2-compat the aforementioned buffer underruns are constanly breaking audio.

[vanfanel]

More information on this.
I can somewhat workaround the issue if I use dmix by setting my /etc/asound.conf like this:

pcm.!default {
    type plug
    slave.pcm "dmix:Generic,8"
}

ctl.!default {
    type hw
    card Generic
}

This way, audio is correct but underruns appear on the console when the games are not sending audio samples (for example before the game starts sending samples or bewteen scenes where the game stops sending samples...):

ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred

[slouken]

Does this happen with the included loopwave test program?

[vanfanel]

Does this happen with the included loopwave test program?

Yes, it happens as it starts, but it doesn't show any more underruns after that:

manuel@debian:~/src/sdl3/sdl2-compat/b5/test$ ./loopwave
INFO: Available audio drivers:
INFO: 0: alsa
INFO: Using audio driver: alsa
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred

...which is what SDLPop and the other games do with the same /etc/asound.conf that activates dmix.
As I said, with dmix there are no audio dropouts, simply those ALSA buffer underrun messages on the TTY.

[slouken]

ALSA underrun is expected if the application isn't feeding audio data, which will happen at startup or if it isn't playing any audio. I think we can fix this by adding silence if we don't have anything to mix, but we might end up increasing latency if we do this. @icculus, thoughts?

[icculus]

Let me poke at this, I'm surprised it's working different between SDL2 and sdl2-compat in this regard.

[icculus]

So, SDLPoP already feeds silence if it doesn't have anything else to do, afaict:

https://github.com/NagyD/SDLPoP/blob/77f833a3c378a70d3448a12fd365b26dfc531112/src/seg009.c#L2100

It's using a standard SDL2 audio callback, so this is going to feed data (even if just silence) from a background thread, even on level load, unless I'm misunderstanding.

(There are calls to SDL_LockAudio, which would prevent the callback from running, but they seem to only be to protect a few variable assignments. It also calls SDL_PauseAudio(), but in these cases, the audio device thread will feed ALSA silence here and just not call the game's audio callback.)

So something else is going on here; we'll need to dig further.