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

[David Henningsson]

On 07/17/2012 07:29 AM, Arun Raghavan wrote:
> [x-posting back to pulseaudio-discuss since it's relevant to both lists]
>
> On Tue, 2012-07-17 at 09:38 +1200, Matthew Gregan wrote:
>> I'm investigating an issue in Firefox's audio code when the PulseAudio ALSA
>> plugin is in use.  I posted about this on pulseaudio-discuss last week
>> (http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-July/014091.html),
>> but I hoped I might have more success here.
>>
>> 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 configure the stream with larger
>> buffer_attr values (e.g. because the minimum sink latency has increased over
>> time due to underruns on the server, or because the sink hardware doesn't
>> support lower latency), but this isn't reflected in pcm->buffer_attr or
>> higher layers in ALSA (i.e. pcm->buffer_size is not updated).

100 ms of latency is a lot, even for PulseAudio - is this some special 
hardware?

>> 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.
>>
>> In the case of the PA server's minimum latency increasing over time, this
>> also means that a stream that was configured and running correctly may break
>> while running if PA increases the minimum latency above what the PCM was
>> originally configured with.
>>
>> 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, 55ms
>> works and 54ms 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

Could you clarify what versions of PulseAudio and alsa-plugins you're 
using? The latest improvement to this handling was done less than a year 
ago and might require the latest versions of these components.

>> (Note that when I reported this on pulseaudio-discuss, my server's minimum
>> latency was 45ms, and now pacmd list-sinks | grep configured\ latency
>> reports a minimum latency of 56ms)
>>
>> 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.

I think the better solution would be nr 2 in this case. Nr 1 won't solve 
the case where the sink's latency is increased dynamically - because the 
stream is moved, for example.

>> Presumably this could be achieved by having the PA plugin report valid
>> values from pcm_pulse.c:pulse_hw_constraint, but I'm not sure how to query
>> the necessary values from the server.  This also wouldn't address the
>> problem where the buffer_attr changes over time, and I'm not sure what to do
>> about that case.
>
> The necessary values are available via pa_stream_get_buffer_attr().
> Potentially we could use this in the pulse_pointer() function to update
> the corresponding snd_pcm_t's period/buffer sizes, but I don't know if
> this is kosher with regards to what alsa-lib expects plugins to be
> doing.
>
> If this is not sufficient for the initial update, from what I can see,
> snd_pcm_set_params() first sets period/buffer sizes, queries them for
> later calculations, and then commits them with snd_pcm_hw_params(). If
> we could move the querying to after the params are committed (and in
> this case, the stream is connected and buffer attributes are
> negotiated), that would solve your problem. Again, I'm not sure what
> side-effects this might have, but I've attached a draft untested patch
> for it.

I don't know either - and it also does not seem to solve the case where 
the sink's latency is suddenly increased (e g, when the sink input is 
moved to another sink).


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic