2010/7/13 David Henningsson launchpad.web@epost.diwic.se
2010-07-13 07:08, Raymond Yau skrev:
2010/7/10 David Henningsson launchpad.web@epost.diwic.se
PA developer often complain the driver did not provide accurate
playback
position by the pcm_pointer callback
Did the pulse_pointer callback also provide accurate position of the
pulse
device ?
Yes, but it provides the pointer to the fake ring buffer (the alsa-lib plugin system expects that all pcm plugins are ring buffers, which seems to me like a design flaw).
This mean that pulse_pointer jump suddenly when PA wake up from sleep and write audio to sound card until the ring buffer is empty, Those "0 bytes
in
queue " message is the result of PA server flush the ring buffer.
Did alsa-lib regard this condition as underrun, since the application pointer and hardware pointer of the pulse device seem at the same point
?
No, I don't think so. An underrun message is a special message sent from the PA server and should not be directly related to the fake ring buffer, and it is that message now being ignored (configurable, thanks to Takashi).
In fedora 13 , the two underrun messages appear almost immediately after starting mpg123 but mpg123 does not report any underrun on Fedora 10
So it look like regression in PA server side if you told me that "An underrun message is a special message sent from the PA server " instead of underrun detected by alsa-lib by checking the pulse_pointer and the application ptr of the pulse device
Under what condition did PA server send the underrun message ?
My first patch (http://git.alsa-project.org/?p=alsa-plugins.git;a=commit;h=1675414) fixes so that if pa_stream_writeable_size returns a value greater than the ring buffer's size, it only reports size-1 bytes available, which means that the alsa app won't see it as the application pointer and hw pointer being the same.
Is this the reason why alsa-time-test.c fail on the pulse device ?
No idea, haven't looked further into that application.
// David