Re: Immediate underrun with PulseAudio ALSA plugin when PA and ALSA buffer sizes differ

[Raymond Yau <superquad.vortex2@gmail.com>]

2012-7-17 上午5:39 於 "Matthew Gregan" <kinetik@flim.org> 寫道：
>
> 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.

this function does not work for all sound card drivers.

many pci sound cards have hardware constraints which you cannot select 10ms
or 100ms period time / buffer time.

> 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).
>
> 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.

do you mean the pulse plugin advertise a low latency but the server in fact
force the application to use a large buffer with high latency?

>
> 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
>
> (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.

there is no negotiation between pa client and pa server about the
capability of different sound cards and you cannot change the peiod
time/buffer time when there are another pa client(s) already
playing/capturing

>
> 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.
>
> Thanks,
> -mjg
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel