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