Re: alsa pulse bugs

[Colin Guthrie <gmane@colin.guthr.ie>]

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.

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