[pulseaudio-discuss] alsa pulse bugs

[tom at dbservice.com]

Quoting Colin Guthrie <gmane at colin.guthr.ie>:

Attached patches to #3943 and #3944. Please read the comments there.

> 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.

Your arguments seem reasonable. Let's see what others have to say to  
it. It would be interesting to see how much delay such change  
introduces. I can't test PA over network at home, but if someone  
wants, the patch is attached to the bug entry in the alsa bugtracker.

>>> 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
> comments :)

tom