Re: [alsa-devel] [pulseaudio-discuss] alsa pulse bugs
Quoting Colin Guthrie gmane@colin.guthr.ie:
Attached patches to #3943 and #3944. Please read the comments there.
tom@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
participants (1)
-
tom@dbservice.com