[alsa-devel] [PATCH] Two patches for Alsa-plugins (pulse)

Raymond Yau superquad.vortex2 at gmail.com
Tue Jul 13 10:32:39 CEST 2010


2010/7/13 David Henningsson <launchpad.web at epost.diwic.se>

> 2010-07-13 07:08, Raymond Yau skrev:
> > 2010/7/10 David Henningsson <launchpad.web at 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
>


More information about the Alsa-devel mailing list