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
