Jack_iodelay is giving wrong results

[unfa]

Hi!

I’ve been using jack_iodelay to set up my JACK server latency compensation in Ardour.

However it recently it seems to be broken:

864.679 frames     18.014 ms total roundtrip latency
extra loopback latency: 4294967148 frames
use 2147483574 for the backend arguments -I and -O

For comparison, this is what Ardour measured for ALSA backend using the same device, same latency and same hardware loopback wire being used:

However Ardour doesn’t provide this calibration for JACK - only ALSA.

Can anyone fix jack_iodelay?

[x42 (Robin Gareus)]

None of the Ardour developers are involved with JACK (anymore).

jack_iodelay is a fork of Fons Adriaensen’s jack_delay. jack_iodelay is part of https://github.com/jackaudio/tools Issues are best reported there.

[unfa]

Thanks. I’ll report the issue there.
I wonder if Ardour’s tool was originally based on this program though?

[unfa]

I’ve e-mailed falkTX about this problem.

Now I’ve used the Ardour-given delay values in JACK, but the recordings are not aligned properly:

Here’s me tapping along to the click and how it looks in the grid.
I’m not a great bass player, but I can at least tap to click, and listening to the recording shows me that the recording latency compensation is off.

Now - just to make sure I’ve switched Ardour to ALSA backend, and the results are the same:

My audio interface is Behringer UMC202HD (USB 2.0).

Here’s my system details:

██████████████████  ████████   unfa@unfa-desktop 
██████████████████  ████████   ----------------- 
██████████████████  ████████   OS: Manjaro Linux x86_64 
██████████████████  ████████   Kernel: 5.6.15-1-MANJARO 
████████            ████████   Uptime: 4 days, 12 hours, 52 mins 
████████  ████████  ████████   Packages: 2275 (pacman), 4 (flatpak) 
████████  ████████  ████████   Shell: bash 5.0.17 
████████  ████████  ████████   Resolution: 1920x1080, 1920x1080 
████████  ████████  ████████   DE: Plasma 
████████  ████████  ████████   WM: KWin 
████████  ████████  ████████   Theme: Breath [Plasma], Breath-Dark [GTK2/3] 
████████  ████████  ████████   Icons: breath [Plasma], breath [GTK2/3] 
████████  ████████  ████████   Terminal: yakuake 
████████  ████████  ████████   CPU: AMD Ryzen 7 1700 (16) @ 3.000GHz 
                               GPU: AMD ATI Radeon RX 470/480/570/570X/580/580X/590 
                               Memory: 16831MiB / 32113MiB

[x42 (Robin Gareus)]

@unfa

Now - just to make sure I’ve switched Ardour to ALSA backend, and the results are the same:

They look different to me, different offsets.
Is this done by recording the metronome using a physical cable? Click-out -> Track in?

@unfa

My audio interface is Behringer UMC202HD (USB 2.0).

You need to measure them every time with USB devices. For this reason Ardour/ALSA allows to calibrate the systemic-latency while running.

Hardware latency not constant?

USB devices on Linux have different systemic latency every time they’re started (and every time after a x-run). This is due to additional kernel side buffering. PCI[e] and Firewire devices are not affected by this. There is a technical explanation by ALSA developer Clemens Ladisch in this thread in jack-devel. The USB driver adds up to an extra period, but at most a 24 ms buffer.

[mhartzel (Mikael Hartzell)]

The jack_iodelay reported value seems like it has overflown a 32 bit value (unsigned integer). Is there any possibility that the measurement gives you a negative value for some strange reason (faulty cable, wrong connection in jack or something) ?

32 bits = 4294967296
(your measurement) 4294967148 - (max 32 bit number) 4294967296 = 148.

[x42 (Robin Gareus)]

My suspicion is that the jack-tool does not ignore existing configuration, so it’s relative to the currently configured one. – or alternatively if it does ignore the config (port latency), jack2’s --sync mode is not taken into account. Those are just educated guesses though.

PS. in either case for USB devices + JACK, the best one can do is to use an average systemic latency (for a given buffer-size).

[mhartzel (Mikael Hartzell)]

I’m on Manjaro too and I don’t have this problem. jack_iodelay reports sane numbers. I just did some tests starting jack with QJackCTL with and without latency settings (-I / -O 256) and jack_iodelay seems to totally ignore the value.

I’m guessing somehow you’re getting a negative value for the measurement and that gives you the number you are seeing. Alternatively you could try 148 for -I and -O and see if your recordings are then in sync. Negative 148 seems to be the number your measurement gets.

My software versions:
jack 0.125.0-9
QjackCTL 0.6.2-1
jack_iodelay comes in the same install package as jack 0.125
Kernel: 5.4.44-1-MANJARO
Desktop: Xfce

[unfa]

@x42

They look different to me, different offsets.
Is this done by recording the metronome using a physical cable? Click-out -> Track in?

No this is me taping to the click on an instrument. So small differences are most likely my human error.

@unfa

Here’s me tapping along to the click and how it looks in the grid.

I could record the metronome in, but I don’t think it’d make a difference.

@mhartzel

Alternatively you could try 148 for -I and -O and see if your recordings are then in sync. Negative 148 seems to be the number your measurement gets.

Hmm. Ardour measured 247 frames of delay for both Input and Output, so I’ve used these values. But they produce bad alignement.

Maybe I’ll reset them to 0 and try to measure again.

This latency calibration used to work great, but right now it seems to give me skewed results.

[agus.terol]

I can confirm it does not ignore existing configuration, because I have obtained similar results. The second time I calibrated with jack_iodelay for confirming that -I/-O values were correct, it reported a tinier value for -I/-O like, for instance, 27 samples or -22, but it seems that the program uses unsigned values for -I/-O, resulting in the second case in an underflow of (2^32-1)-22. That’s probably why @unfa obtained that “huge” values, because of the second measure (USB device restart, so surely different system latency) being lower, resulting in a underflow, and the program showing weird values.

To clarify:
1st measure (-I/-O is set to 0): real systemic latency 400 samples, reported 400 samples, so -I/-O is reported to be 200 samples.
2nd measure (-I/-O now are set to 200): real systemic latency 350 samples, reported -50 samples (because -I/-O correction), so -I/-O should be -25 samples. Since these values are reported using 32 bits unsigned integers they will be shown as 4294967245 samples and 2147483622, respectively.

[agus.terol]

My suggestion is to record the metronome in. Independently if it makes a difference or not, it will be a more accurate experiment. I am not judging your bassist skills

So, after calibrating, do not remove the cable, and record Ardour’s metronome click in a track with the record/input port you set in the calibration dialog. Also, route the click to the playback/output port.

More people experimenting similar behavior with USB devices here, here and here.