Different latency values in Ardour and qjackctl

[fjalar (Matthias)]

I have noticed that Ardour always displays the half amount of latency that qjackctl shows. Here are my qjackctl settings:

which isn’t terribly exciting (10.7 ms of latency, well…)

Ardour, however, shows half the value:

I have noticed that whatever I’m setting in qjackctl, Ardour always shows the half value. So which one is right?

[x42 (Robin Gareus)]

As for Latency: neither is correct.

Ardour shows the process block-size, not the latency. The Round-trip latency is given by

(N + 1) * block-size / sample-rate + systemic-i/o latency

With default jack2 (async mode), and 2 periods/buffer, N = 2. The systemic-latency has to be measured (and calibrated).

[fjalar (Matthias)]

I understand that the “latency” display in qjackctl is at best misleading then.

[x42 (Robin Gareus)]

It is the best case value for round-trip latency.

Say the soundcard collects block-size audio-samples. e.g. 1msec (48 samples / 48kHz).
After this is complete, the samples are immediately processed and the result is placed on the output buffer for the next cycle. The result becomes audible 2 msec after it was captured:

This is what happens with jack1 (or when running jack2 in --sync) mode using 2 periods:

time   ------------>
Capture    A B C D
Process    - A B C  
Play       - - A B

At best, audio-data is audible exactly two cycles after it was captured. This does not account for systemic latency (additional buffers in the driver or the device or hardware).

Note that jackd2’s async mode (enabled by default) adds one extra period of latency. qjackctl’s info does not account for this.

PS.
see also https://manual.ardour.org/synchronization/latency-and-latency-compensation/
with JACK you can measure the round-trip latency using jack_iodelay (comes with JACK) to establish the additional systemic latency of your system.