[pulseaudio-discuss] Immediate underrun with PulseAudio ALSA plugin when PA and ALSA buffer sizes differ

Matthew Gregan kinetik at flim.org
Tue Jul 10 23:28:08 PDT 2012

I'm investigating an issue in Firefox's audio code when the PulseAudio ALSA
plugin is in use.

It wasn't clear if PulseAudio ALSA plugin issues should be raised here or on
alsa-devel, so please let me know if this is the wrong forum for this issue.

Firefox requests a particular latency (100ms, 4410 frames at 44.1kHz) via
snd_pcm_set_params.  Inside the plugin (pcm_pulse.c:pulse_hw_params), that
value is used to set up buffer_attr.  When the PA stream is connected in
pcm_pulse.c:pulse_prepare, PA may increase the buffer_attr values, but this
isn't reflected in pcm->buffer_attr or higher layers in ALSA.

Would a possible fix for this be to query pa_stream_get_buffer_attr after
connecting and update pcm->buffer_attr and the higher (ioplug/etc.) layers
that the buffer size has increased?

The problem I'm faced with is that there doesn't appear to be a way to
detect and handle this issue at the ALSA API level, and requesting a too low
latency results in broken audio playback rather than a PCM setup failure or
a larger buffer than requested being used.

I've attached a simple testcase that uses snd_pcm_wait,
snd_pcm_avail_update, and snd_pcm_writei.  Run it with a latency argument
specified in milliseconds on the command line.  For my local machine, 45ms
works and 44ms fails immediately like so:

snd_pcm_wait wakes
snd_pcm_avail_update returns 4410
snd_pcm_writei writes 4410
snd_pcm_wait wakes immediately
snd_pcm_avail_update returns -EPIPE

I'd expect to see one of the following behaviours instead:
1. PCM setup fails due to requesting a too small buffer.
2. Buffer is silently raised during setup and snd_pcm_avail_update requests
   the correct number of frames.
3. PCM wakes from snd_pcm_wait for refill enough times to fill the buffer.

As a side note: this seems to be related to the PA server increasing the
minimum latency over time.  Once the PA server is in this state, restarting
it (in non-daemon mode with debug logging or via pulseaudio -k and
autospawn) causes the problem to disappear.  After restarting the server, I
can run the testcase with 44ms and lower latency successfully.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: latency.c
Type: text/x-csrc
Size: 1500 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20120711/f38c0dcb/attachment.c>

More information about the pulseaudio-discuss mailing list