[alsa-devel] [PATCH] Alsa-plugins: Pulse: Fix snd_pcm_avail returning 0 in some cases

Raymond Yau superquad.vortex2 at gmail.com
Wed Apr 27 03:00:56 CEST 2011


2011/4/26 David Henningsson <david.henningsson at canonical.com>

> On 2011-04-22 01:25, Raymond Yau wrote:
>
>> 2011/4/21 David Henningsson<david.henningsson at canonical.com>
>>
>>  Due to a round-off error, snd_pcm_avail could in some cases
>>> return 0 even though more data could be written to the stream.
>>>
>>> This was discovered by Maarten Lankhorst [1], and there is also a test
>>> program available that triggers this error [2].
>>>
>>> [1]
>>>
>>> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-April/009935.html
>>>
>>> [2]
>>>
>>> https://tango.0pointer.de/pipermail/pulseaudio-discuss/attachments/20110420/3c852d6e/attachment.c
>>>
>>>
>> if the test program can force under-run occur with "hw" device and "pulse"
>> device with his patch in
>>
>> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-April/009918.html
>>
>> Is it normal that underrun does not occur with the test program and your
>> patch
>>
>
> Yes; underruns are not reported to the application due to the risk of the
> underrun being obsolete at that time. As for Maarten's patch in the post you
> refer to,
>
> 1) if underruns are being reported (this is configurable), it might be a
> good idea to call "pulse_start".
>
> 2) it changes underruns to being reported by default, which is what I'm
> opposed to.
>
> >>> However if I force underruns to occur, the state will stay running and
it appears
>>> there is still some data left in the buffer, so sound stalls entirely.
The latency gets >>> updated to something like 0x7bdXXXXXXXXXXXXX which
looks suspiciously
>>> much like a pointer to me, which may be a bug.
>>> So my questions are.
>>> 1. Is the weird latency value update a bug? Digging it up I can only
assume it's a
>>> bug in src/stream.c , but I haven't figured out why yet.  Tested with
pulseaudio.c
>>> 2. Any comments on this patch for alsa-plugins?

There are some difference between devices "hw" , "plug:dmix" and "pulse"
when I run "aplay -v --test-position any.wav" with different period size and
buffer size

It seem that the delay of  device "pulse" is much larger than those of
"dmix" and "hw"


More information about the Alsa-devel mailing list