[pulseaudio-discuss] Best Case Latency

[Patrick Shirkey]

On Sat, September 28, 2013 2:58 am, Patrick Shirkey wrote:
>
> On Sat, September 28, 2013 12:53 am, Tanu Kaskinen wrote:
>>> On Fri, 2013-09-27 at 23:31 +1000, Patrick Shirkey wrote:
>>>
>>> At the moment I'm trying to pin down the cause of the consistent and
>>> reproducible but fluctuating latency results that I see with this
>>> machine.
>>> I am doing this in order to get the hard data I need to present the
>>> JACK
>>> +
>>> PA solution as the better method.
>>
>> One of the unclear things is what other method you are comparing the
>> "JACK + PA solution".
>>
>
> The other option is to use JACK exclusively while it is running. The opens
> a can of worms that I would rather didn't have to be opened.
>
>
>>> So far I cannot point the finger at any
>>> specific process or bottleneck. Given that I am apparently the only
>>> person
>>> in the world who has the time and/or motivation to run these tests we
>>> are
>>> working with the small dataset that I can provide. All your feedback is
>>> crucial and very useful as I do not have the complete overview of PA
>>> codebase like yourself or others on this list.
>>>
>>> To recap, I have tested with two jack graphs.
>>>
>>> 1: jack_delay -> pa -> ecasound -> pa -> jack_delay
>>>
>>> The latency starts low and then consistently climbs (see below).
>>>
>>> 2: jack_delay -> pa -> ecasound -> pa -> system_out -> system_in ->
>>> jack_delay
>>>
>>> The latency jumps around from anything between 4ms to 1300ms. It might
>>> also go lower but I didn't see that yet.
>>>
>>> - Here's an interesting snapshot for consideration captured just now
>>> while
>>> running graph 1. The latency captured while polling with "pactl list
>>> sink-inputs" is the same as the previous snapshot (approx 10ms).
>>>
>>> ex.
>>> 	Buffer Latency: 8000 usec
>>> 	Sink Latency: 3166 usec
>>>
>>> However, jack_delay reports the following data. Where you see ?? that
>>> indicates a dropout in the audio stream so jack_delay was not able to
>>> make
>>> a real measurement so guessed.
>>
>> What do you mean by "dropout"? An xrun reported by jackd? Note that
>> there are several different kinds of underruns and overruns that can
>> occur. One kind is the case where jackd is late to read/write to the
>> sound card (alsa). Another kind is when pulseaudio is late to read/write
>> to jackd (I'm not sure if this will always translate also to alsa level
>> under/overruns too). Third kind is when ecasound is late to read/write
>> to pulseaudio (this is what I'll refer to as "stream under/overruns",
>> and these are invisible to the jack domain).
>
> Any or all of the above. Basically a discontinuity in the stream which
> means jack_delay cannot complete the signal loop temporarily.
>
>
>> Do you get logs about each
>> of these? I don't remember if the alsa compatibility layer forwards the
>> stream under/overrun notifications to the alsa application - IIRC there
>> were problems when those were reported and there were different problems
>> when those were not reported, and I don't remember what the current code
>> does.
>>
>> I don't know if distinguishing between the different kinds of
>> under/overruns is really important at this point, though. Changes in the
>> latency probably happen when there is some kind of an under/overrun, but
>> that doesn't help much with figuring out in which buffer the audio is
>> accumulating.
>>
>
> Another location that hasn't been discussed could be the point between
> ecasound and PA (the intermediate alsa layer)
>
>
>>> jack_delay -> pa -> ecasound -> pa -> jack_delay
>>>
>>> ---------------
>>> 62784.000 frames   1308.000 ms total roundtrip latency
>>> 	extra loopback latency: 62784 frames
>>> 	use 31392 for the backend arguments -I and -O
>>>  62784.000 frames   1308.000 ms total roundtrip latency
>>> 	extra loopback latency: 62784 frames
>>> 	use 31392 for the backend arguments -I and -O ?? Inv
>>>  63168.000 frames   1316.000 ms total roundtrip latency
>>> 	extra loopback latency: 63168 frames
>>> 	use 31584 for the backend arguments -I and -O
>>
>> What's the interval of these measurements? I mean once per 10 seconds or
>> something like that? (Just trying to get a better understanding of the
>> rate of the latency changes.)
>>
>
> Approximately every second. I will try again with a possibly newer version
> of jack_delay in case that helps.
>

This is with a newer version of jack_delay which I didn't know about until
a few minutes ago.

http://boosthardware.com/pa-jack-latency-2.txt

The results are better which is encouraging but the variation is still
happening just on a smaller scale.


>
>> Since "pactl list sink-inputs" doesn't show any abnormal behaviour, it
>> looks to me like the next step is to either add extra logging to each
>> point in the audio path that deals with buffering (print the amount of
>> buffered audio), or write the measurement application that you were
>> planning to do (that should find out whether the bad buffer is in the
>> input or output path, but still doesn't pin-point the bad buffer).
>>
>

Looks like this might be required now.



--
Patrick Shirkey
Boost Hardware Ltd