2011/4/26 David Henningsson david.henningsson@canonical.com
On 2011-04-22 01:25, Raymond Yau wrote:
2011/4/21 David Henningssondavid.henningsson@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.htm...
[2]
https://tango.0pointer.de/pipermail/pulseaudio-discuss/attachments/20110420/...
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.htm...
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,
- if underruns are being reported (this is configurable), it might be a
good idea to call "pulse_start".
- 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.
- 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
- 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"