SDL sample count adjustable via environment variable (in Linux)? Actual sound lag.

Any application with SDL sound shows sound lag. It can be from ms's to whole seconds. Only way to sort of avoid this is using aoss prior to running program; e.g.: `aoss chocolate-doom -iwad DOOM.WAD`. OSS emulation is enabled through aoss alsa sound driver. Buffers may still need to be reduced.

Found it made a huge difference editing prboom-plus's SAMPLECOUNT in i_sound.c:

sed -i 's|static int SAMPLECOUNT =   512;|static int SAMPLECOUNT =   64;|g' src/SDL/i_sound.c

Same thing when changing chocolate-doom's sound_slice_time in i_sdlsound.c:

sed -i 's|MAX_SOUND_SLICE_TIME) / 1000;|MAX_SOUND_SLICE_TIME) / 3000;|g' src/i_sdlsound.c

Those changes really reduced sound lag, if anything it's gone.

Any SDL environment variable that gives the same effect as those edits? What about editing the SDL library itself (checked sound/alsa/*.c but found nothing)?

For the record, I'm using the following SDL environment variables already:

export SDL_AUDIO_ALSA_SET_BUFFER_SIZE=0
export SDL_AUDIO_ALSA_SET_START_THRESH=0
export SDL_AUDIO_ALSA_SET_PERIOD_SIZE=0

Help is much appreciated!

Regards

Is this because you're using Pulseaudio?

fraggle said:

Is this because you're using Pulseaudio?

If it works better with aoss, then I asume he is *not* using pulseaudio (but maybe should).

No pulseaudio here. Just plain alsa. Just found out aoss doesn't completely resolve sound lag (but it helps a bit). Changing source code seems like the only option so far...

EDIT:
Sound lag is completely gone after source code edits without aoss. aoss actually introduces lag after these changes.

fraggle said:

Is this because you're using Pulseaudio?

It might be because I'm using a real sound-card (instead of onboard sound). It does hardware mixing (which is really nice since I have alot more CPU time now; Can play up to 32 or 64 sounds simultaneously I think). With previous onboard sound, I used dmix (software mixer for alsa) and experienced no sound lag at all despite insane cpu time with libsamplerate (could change audio buffers and periods through .asoundrc); it did exhibit lag with hardware mixer though (and it only played one source at a time). Think this is related to hardware mixing code using high buffers or similar...

Holering said:

No pulseaudio here. Just plain alsa.

It depends on the sound sever that you use in your system. If you use plain ALSA but mangle your sound through aoss to convert it into OSS format which in turn gets transformed back to ALSA by the Alsa-OSS compatibility layer, then no wonder that you suffer from latency.

I supect that SDL is configured for the wrong sound server on your system. Please try to run "SDL_AUDIODRIVER=alsa chocolate-doom" and try with different backends - e.g. dsp, dma or pulse - instead of alsa.

Sounds like Holering isn't using a sound server, but I agree that SDL_AUDIODRIVER=alsa is a good thing to try.

I'd be surprised if hardware mixing caused something like this: it's the kind of thing I expect to see when using software mixing.

Holering said:

EDIT:
Sound lag is completely gone after source code edits without aoss. aoss actually introduces lag after these changes.

After the MAX_SOUND_SLICE_TIME change? That makes sense. I should probably add a config variable to allow that to be tweaked, and possibly make the default smaller.

Your change should be to reduce MAX_SOUND_SLICE_TIME to be smaller, not change that 1000 divisor (which makes no sense). Probably 28ms is a more sensible value: ie. one sound slice per gametic.

SDL_AUDIODRIVER="dma" SDL_PATH_DSP="/dev/dsp" SDL_AUDIO_ALSA_SET_START_THRESH="0", fixed most SDL lag with alsa hardware mixer. Don't think audio buffer needs to be reduced either. YAY!!! So nice having more cpu time and better sound performance (no software mixing) :)

EDIT:
Lots of useful environment variables with descriptions in case others have *NIX systems with sdl trouble (or tweaking in mind): http://www.libsdl.org/release/SDL-1.2.15/docs/html/sdlenvvars.html

Now if I can only get x11 video to vsync...

It turns out the application won't necessarily get the audio buffer size it asks for when calling SDL_OpenAudio (in many cases via Mix_OpenAudio). The particular SDL sound driver used is free to change it.

from SDL_OpenAudio(3)
Since the audio driver may modify the requested size of the audio buffer, you should allocate any local mixing buffers after you open the audio device.

Holering said:

SDL_AUDIODRIVER="dma" SDL_PATH_DSP="/dev/dsp" SDL_AUDIO_ALSA_SET_START_THRESH="0", fixed most SDL lag with alsa hardware mixer. Don't think audio buffer needs to be reduced either. YAY!!! So nice having more cpu time and better sound performance (no software mixing) :)

To clarify: does this fix the problem without the need for your code change?

RjY said:

It turns out the application won't necessarily get the audio buffer size it asks for when calling SDL_OpenAudio (in many cases via Mix_OpenAudio). The particular SDL sound driver used is free to change it.

Interesting. In addition to the config variable idea I proposed above, it's probably a good idea if I add something to detect this case.

No. Sorry for the mispost. Still have to reduce buffer size through code change and use the SDL variables from my last post.

I filed a bug yesterday to fix this up.

Bug is fixed; 28ms is now the default and there's a config variable to adjust it if you want.