[alsa-devel] [PATCH] Alsa-plugins: Pulse: Fix snd_pcm_avail returning 0 in some cases
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 , and there is also a test
>>> program available that triggers this error .
>> if the test program can force under-run occur with "hw" device and "pulse"
>> device with his patch in
>> Is it normal that underrun does not occur with the test program and your
> 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
>>> there is still some data left in the buffer, so sound stalls entirely.
The latency gets >>> updated to something like 0x7bdXXXXXXXXXXXXX which
>>> 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
>>> 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
It seem that the delay of device "pulse" is much larger than those of
"dmix" and "hw"
More information about the Alsa-devel