Can someone tell me if I’ve done this right…

I connected my M-Audio 2496 hardware outputs to hardware inputs, ran jack_iodelay, connected it up and got this:

128.000 frames 2.667ms

In qjackctl I’ve got:

frames/period 128
sample rate 48000
periods/buffer 2

According to the manual (http://dev.man-online.org/man1/jack_iodelay/), I now subtract periods from the measured delay:

2.667 - 2 = 0.667

…and then enter half this value (0.334) for both input latency and output latency.

However it’s not actually possible to enter such a small number - qjackctl will only accept whole numbers for input & output latency which makes me think I’ve probably got an error in my calculation.

Thanks for your help.

when i did the above i got some strange results…
what i ended up doing was go “empirical”.
Put your headphones over your mic and record ardour’s click, see if it comes out on the beat in the recordings…
then look at the time difference and fiddle with input latency and output latency until all is good.
(well actually maybe one should do the “headphones over mic” thing with jack_iodelay to include the latency of the entire analog chain including the electromechanical bit).

Looks like you might have somehow connected jack_iodelay’s output straight back to its input, which will show you a delay of exactly one period. You need to connect jack_iodelay’s out and in to the system:playback & system:capture ports you’ve physically looped back.

I think that newer versions of jack_iodelay tell you exactly what to set -I and -O to, but otherwise you need to subtract (frames/period * periods/buffer) from the number of frames that jack_iodelay reports, and then set both -I and -O to half of that answer.

Doh! That’s what I did. Thanks Colin.

The reading with everything set up right was:

446.609 frames 9.304 ms

In the manual:

"To use the value measured by jack_iodelay with the -I and -O arguments of a JACK backend (also called Input Latency and Output Latency in the setup dialog of qjackctl), you must subtract the JACK period size from the result. Then, if you believe that the latency is equally distributed between the input and output parts of your audio hardware (extremely likely), divide the result by two and use that for input and/or output latency value.

So, with periods/buffer set to 2 in qjackctl, I get:

(9.3 - 2) / 2 = 3.65

That sounds a bit more like it.

What I understand is that:

Round trip latency measured by jack_iodelay - jack latency (buffer size) = hardware latency [1]

Then you divide the hw latency by 2, and put this value in the Input and Output latency fields.

The unit for all of these values must be frames, not miliseconds.

Note that in jackd2, default mode (async mode),

jack latency = p*(n+1) [2]

In jackd2 sync mode, and in jackd1:

jack latency = p*n [3]

p: frames/period
n: number of periods or periods/buffer

So in your case, with p=128, n=2 and assuming you are using jackd2 in the default mode, you should apply expressions [1] and [2]:

hw latency = jack_iodelay latency - jack latency = 446 - 128*3 = 62 frames

Then you put 31 frames for the -I and -O values.

Note that qjackctl reports p*n/r as the latency (ms) in all cases. This is misleading for the default jackd2 conf.

Anyway, I think it is better running jackd2 in sync mode, adding --sync to the jackd command (“server path” field in qjackctl). If you do so, check the latency again with jack_iodelay and do the above operations [1] and [3]. You will see less total latency but the same hw latency.

Or I think so

See also the jackaudio.org wiki, differences between jackd1 and jackd2, especially note 1.

Cheers, Pablo

Note that jack_iodelay in jack1 svn does all this math for you now.


Can I double check: if jack_iodelay outputs…

X frames Y ms

…and I have Z periods/buffer in qjackctl, then the calculation for input & output latency (in ms) would be:

(Y-Z) / 2

(from http://dev.man-online.org/man1/jack_iodelay/)

“…you must subtract the JACK period size from the result of jack_iodelay…”.

Here, the result of jack_iodelay is the value in frames. The “jack period size” depends on the jack version and configuration:

p*(n+1) frames for jack2 in the default, asynchronous mode
pn frames for jack2 in synchronous mode
n frames for jack1

The result is the hw latency in frames, and you divide by two to set the input and output latency… also in frames.

If you divide frames by the jack sample rate in kHz, you have these values in miliseconds. The values in ms are good as a reference but they are not used in these calculations.

Cheers, Pablo

OK I’ve got it now :slight_smile:

frames/period = 128
periods per buffer = 2
I’m running jackd2 with the -S flag
jack_iodelay reports: 446.609 frames 9.304 ms


(446.609-(128*2))/2 = 95.3 for both input and output latency (in qjackctl)

Thanks for your help.