[pulseaudio-discuss] Distribution kernels and glitch-free (Packagers, read this!)

[Lennart Poettering]

On Tue, 12.05.09 15:58, Hynek Hanke (hanke at brailcom.org) wrote:

>
> Lennart Poettering wrote:
>> Which PA version is this?
>>   
>
> Thank you for your quick reply! This is 0.9.14.
>
>>> Our application still gets latency up to 260ms. If initially we set tlength
>>> to 100 and maxlength with a big limit so that Pulse can freely increase
>>> the latency to avoid glitches, it starts with small latency and underruns
>>> and increases it up to 60ms or more again.
>>>
>>> May 12 11:53:29 homer pulseaudio[27727]: protocol-native.c: Final   
>>> latency 19,95 ms = 0,00 ms + 2*9,98 ms + 0,00 ms
>>>     
>>
>>   Uh, that 0,00 looks suspicious.
>>   
>
> When we limited maxtlength to 1000, we got even negative values,
> like -3ms (which displayed as very large positive values in the logs, I
> think due to some kind of overflow, but it was clear from the total sum
> that the numbers were small negatives). I don't know if this is any clue
> for you.

Sounds like a bug. Any chance you retest this with 0.9.15. the latency
configuration changed considerably between 0.9.14 and .15.

Negative values are a sign of that things are really broken.

Could you tell me how you initialized buffer_attr exactly? I would
like to to reproduce this here.

>> Basically, the three values on the right side are per-stream buffer size,
>> request size and hardware buffer size.
>>   
>
> So 0+2*10+0 would mean roughly 20ms delay between the instant when the
> client first requests playback and when the sound is audible in the  
> speakers?
> Just trying to understand...

Yes, kind of. The actual latency in the end *will* differ from
that. But yes, the left side value of 19,95ms should be very near to
the factual max latency during run time, at least on PCI devices.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4