[pulseaudio-discuss] alsa pulse bugs
gmane at colin.guthr.ie
Mon May 5 02:18:23 PDT 2008
tom at dbservice.com wrote:
>> Re the snd_pcm_delay() including network latency (#3945), this clearly
>> makes sense for network streams. Does you proposed fix include this
>> delay (albeit with the improvement that it also will drop to 0 if there
>> are no samples queued)?
> snd_pcm_delay() should not include any network latency. The API is
> defined as 'read pointer - write pointer', and applications expect
> that. Or at least they expect that when all samples are played that
> the delay drops to zero.
With the caveat of very limited technical knowledge, I can agree on the
latter point (drop to 0 when all samples are played), but if it was
implemented sans net-delay in pulse would this not cause e.g. a-v sync
issues when playing via alsa to a networked PA server? If so then this
fix would introduce another bug.
>> Also re #3942, I believe (but not sure) that the max buffer in the
>> glitch free branch has been increased significantly (as it now needs to
>> keep some degree of past sound as well as future buffer to allow the
>> rewinds to work properly (this is no doubt an inaccurate description of
>> why it's needed.... :p)) I'm not sure how this would affect this
>> solution, but Lennart will be able to advise better.
> I'd suggest to export MAX_MEMBLOCKQ_LENGTH in a public API so that
> applications can make use of it. If the max buffer length has been
> increased, then the alsa pulse plugin should be able to propagate that
> to applications using the alsa API.
Well I'm not sure of the internals of the glitch-free stuff, but I doubt
it's a buffer that can be used in quite the same way as that. Lennart
will be able to advise if I've got the wrong end of the stick in my
More information about the pulseaudio-discuss