[LAU] Testing JACK and PA latency

[Patrick Shirkey]

Resending as the first one appears to have been blocked.

On Thu, September 19, 2013 8:46 pm, Fons Adriaensen wrote:
> On Thu, Sep 19, 2013 at 08:04:04PM +1000, Patrick Shirkey wrote:
>
>> > 1. Measure the round-trip latency of your sound card (with an
external analog loop).
>> >
>>
>> Can I use jack_delay running on a second computer connected to the
external i/o of the first computer to get this value?
>
> You'd measure something different...
>
> But you could use two computers as follows:
>
> A = computer with jack, PA, audacity
> B = second computer with sound card, jack and jack_delay.
>
> 1. Measure the round-trip latency on B, with an external
>    analog loop.
>
> 2. Connect B -> A, A -> B, run complete chain on A.
>
> 3. Measure again on B, subtract the value from (1).
>
>> >   jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay.
>> >
>>
>> Does this look reasonable?
>>
>>   1023.978 frames     21.333 ms total roundtrip latency
>> 	extra loopback latency: 1023 frames
>> 	use 511 for the backend arguments -I and -O
>>   1023.976 frames     21.333 ms total roundtrip latency
>> 	extra loopback latency: 1023 frames
>> 	use 511 for the backend arguments -I and -O
>>   1023.977 frames     21.333 ms total roundtrip latency
>> 	extra loopback latency: 1023 frames
>> 	use 511 for the backend arguments -I and -O
>
> Don't know - I'm by no means a PA expert... and I don't know
> your Jack period size. Given PA's reputation I'd expect more:
> 1024 samples would mean that PA imposes almost the same RT-
> requirements on apps as Jack does, and it was designed *not*
> to do that...  But maybe the jack <-> PA interface doesn't
> use the same amount of buffering that PA normally adds.
>
> Note that the value measured is modulo 2^16 samples, but I
> wouldn't expect anything more than a second, so this probably
> irrelevant.
>

Here's a bit more detail for discussion before I send this over to the PA
guys for feedback.

I am seeing the time period returned by jack_delay regularly increase
during the measurement process. Do you have any thoughts on why that would
be happening? I would like to rule out jack_delay because this is most
likely a bug in PA that I have come across now.


I'm using this method:

jack is now set to 64/48000/2

This is the graph:

  jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay

Using audacity with 0 internal latency and in pass through mode I see the
following results. It starts out as 10.667ms and after a few seconds it
climbs up to 70.667 ms.

I see similar results with ecasound instead of audacity using the
following graph and ecachain:

jack_delay -> pa_source -> ecasound -> pa_sink -> jack_delay

ecasound -f:32,2,48000 -b:64 -i alsa -o alsa

In that case it starts at 60.000 ms and climbs upto 572.000 ms after a few
seconds of running the test.

Console logs here:

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


>
>> > 3. If pa_source and pa_sink are a single Jack client (probably not),
>> >    subtract one period from the result of (2).
>>
>> Can you explain that with the data above?
>
> If they are a single Jack client you create a loop in Jack's
> processing graph, this adds one period to the measurement.
>
>
>> > 4. Add the two values.
>> >
>>
>> I would like to provide an app for this task. Do you think it would be
worthwhile to extend jack_iodelay for this purpose?
>
> Don't see how. You need to do two measurements anyway, no matter how
it's done, then add or substract.
>

--
Patrick Shirkey
Boost Hardware Ltd