[pulseaudio-discuss] Best Case Latency

[Patrick Shirkey]

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.


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


--
Patrick Shirkey
Boost Hardware Ltd