[pulseaudio-discuss] alsa pulse bugs

[tom at dbservice.com]

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

> tom at dbservice.com wrote:
>> I reported three bugs to the alsa bugtracker:
>>
>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3942
>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3943
>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3944
>>
>> It's three bugs after all. Once these are fixed I expect Wine to work.
>> *fingers crossed*
>
> Ace Tom :)
>
> I've cross posted this to the alsa devel list. Hopefully Takashi (who's
> committed some pulse-related stuff recently) will have some insight here.
>
> 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.

And no, my current patch does not include network latency at all. It  
simply does what alsa does, 'read pointer - write pointer'.

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

tom