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

[Matthew Gregan]

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.

Thanks,
-mjg
-------------- 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>