ALSA output doesn't set buffer size (likely fix for pulse problems)

SDL Development
1

Hi,

I just noticed that the alsa audio output never set the alsa hardware’s
buffer size. I think this is why SDL has such latencies when pulse audio is
in use.

SDL has a notion of always writing data even when there is only silence,
this means that it will ALWAYS fill any buffer in the audio hardware to
it’s rim.

For the pulse alsa “hardware”, the default internal buffer size is probably
quite huge. This means that this get’s filled, and any audio events
generated by SDL will get queued at the end of this huge buffer.

There is two solutions to this problem

  • implement ALSA_WaitAudio(_THIS) and make it only return if the alsa
    buffer size is less than two times the wanted SDL buffer size
  • call snd_pcm_hw_params_set_buffer_size_near (should be set to two times
    the period size

I haven’t verified this yet, but i’m quite sure it should fix the issue.

Joakim

2

There is two solutions to this problem

  • implement ALSA_WaitAudio(_THIS) and make it only return if the alsa
    buffer size is less than two times the wanted SDL buffer size

This might be the only approach actually, but i’m not sure how as alsa
doesn’t expose any good method to know how much is still in the buffer.

  • call snd_pcm_hw_params_set_buffer_size_near (should be set to two times
    the period size

I’m not sure this will be sufficient anymore, as currently the alsa pulse
"hardware", specifies a maximum buffer size of 4 * 1024 * 1024. It does
respect the set buffer size for the default buffer size, which is when
pulse will ask it’s clients for more data. It will however still accept
data up to the maximum buffer size.

I don’t know if the alsa subsystem will block at the standard buffer size
or the maximum size. seems to be dependent on what pa_stream_writable_size
returns i think.

3

Thanks for looking into this. Some of the Tux4Kids apps have had
problems (esp. on LTSP?) which seemed to be fixed by switching from
Pulse to ALSA. Sounds like you’re discovering it’s something SDL itself
might be able to correct…?

Thx,

-bill!On Wed, Jan 14, 2009 at 03:57:34PM +0100, elupus wrote:

I just noticed that the alsa audio output never set the alsa hardware’s
buffer size. I think this is why SDL has such latencies when pulse audio is
in use.

4

[3 quoted lines suppressed]

Thanks for looking into this. Some of the Tux4Kids apps have had
problems (esp. on LTSP?) which seemed to be fixed by switching from
Pulse to ALSA. Sounds like you’re discovering it’s something SDL itself
might be able to correct…?

Thx,

-bill!

If you mean that you turn of the pusleaudio deamon, then yes.
If you mean switching from SDL’s pulse audio output to SDL’s ALSA output
then no.

SDL has two outputs, one for direct pulse, one for alsa. When pulse daemon
is running, it provides a virtual ALSA device. The fix i’m proposing is for
when you have sdl_alsa_output -> pulse_alsa_device -> pulsedaemon ->
soundcardOn Wed, 14 Jan 2009 18:05:16 -0800, Bill Kendrick wrote:

On Wed, Jan 14, 2009 at 03:57:34PM +0100, elupus wrote: