Jack_iodelay is missing

Hello everybody!

I just installed a new linuxmint version (based on ubuntu 18.04 bionic).

I’m looking for jack_iodelay, but it is not in the repositories anymore! only jack_delay and jdelay are in the repository. I’m looking for jack_iodelay because it was updated and the output was much more understandable :slight_smile:

Where is it ? Also I couldn’t find it anywhere on the internet… this is really strange! Did I miss something?

Thank you in advance
all the best


jack_iodelay is part of JACK 1. You are using JACK 2.

Thank you for the answer Paul!
It seems my fresh system installed jack2 by default.
Why jack_iodelay is not part of jack2 as well? Is it jack1 specific?
Any chance to have jack_iodelay also working in Jack2 ? or should I downgrade?

This is a long standing issue with the two versions of JACK. jack_iodelay is part of the tools/ folder of JACK1. It was intended that this folder would (eventually) be shared between both versions, but this never happened. As a result, JACK 2 has its version of jdelay (Fons’ original program), jack_delay, and JACK1 has its version, jack_iodelay. Each one will work with either version of JACK, but packaging in distributions will only give you one version.

Thank you Paul for the answer!
okay I see I will need to learn to understand the output of jack_delay… any hint how to get the proper values out of it for the latency compensation?
All the best


You’re probably thinking of the include/ folder. The tools folder is shared between the two projects (it used to be copied into tree, but I think falktx did some recent merge to share it). On debian/stable:

$ dpkg -S /usr/bin/jack_iodelay
jackd2: /usr/bin/jack_iodelay

Regarding latency, keep in mind that jackd2 adds an extra cycle of latency when it is running in async mode.

With respect to Ardour: Don’t use JACK, use Ardour’s built-in ALSA backend. Ardour’s Engine Dialog has a GUI to measure latency and also allows to calibrate systemic MIDI latency per MIDI port.

Hello Robin,

With respect to Ardour: Don’t use JACK, use Ardour’s built-in ALSA backend. Ardour’s Engine Dialog has a GUI to measure latency and also allows to calibrate systemic MIDI latency per MIDI port.

Why should I use Alsa instead of Jack? I’m using Ardour with a Firewire RME800 and as far as I know I need to stick to Jack/FFADO. Could you please give me shortly the pros and cons?

I did the latency mesurement wit ardours’ build-in latency mesurement tool, but it didn’t work,even after a jack restart. :frowning: But, after putting ardour’s latency mesurement values into qjackctl, it works perfectly. :slight_smile:

My question is: Is there any in-depth documentation about the math and magic behind these latency mesurement and compensation? I really would like to write an article about this… because I was trying for ages to get it working and I would love to have a proper documentation about this somewhere on the internet. I tried some reverse-engineering, and I get the attended results, but with different period amount, and I get confused… looking at forums theads is also confusing because there are so many different answers.

Thank you in advance!

Vince (Superdirt²)

Did you read the man-page of jack_iodelay? What would you add? Maybe just update the man page and add some “Example” section?

When it comes to users, I don’t think we need another article. We should provide some easy, self-explanatory tool to guide the user and get the measurement done. Ardour’s Engine-Dialog aims to provide that, but as you have found out, it is Ardour specific.

PS. I though the ALSA snd-fireface driver is already complete.

Hello Robin,
thank you for your answer!

I completely agree about the users. But, actually I had a typical user-case: I installed a fresh new Linuxmint and installed jack (jack2 was installed by default). I wanted to start jack_iodelay but it was missing… only jack_delay and jdelay in the repositories. But jack_delay and jdelay don’t do the math for the -I and -O arguments. I got completely confused and started this thread. If an article was there to figure out all information in this thread, this would have been so helpful. Nethertheless, now we have this thread, I will gather all information in the next post.

I’d love to do that, where can I update the manpage?

I didn’t know about this I will try it asap, but unfortunately snd-fireface is not in my repositories (ubuntu bionic)…is there a ppa somewhere or should I compile it by myself?

Thank you for the input!

1 Like

jack’s git repo: https://github.com/jackaudio/jack2/blob/master/man/jack_iodelay.0

apparently those man-pages are also copy/pasted (not shared) between jack1, jack2. but I think falktx said jack1 is EOL and all new changes should go to jack2’s repo.

https://github.com/takaswie/snd-firewire-improve#readme has modules available as DKMS. I don’t know how it compares to FFADO/JACK. perhaps staying with JACK/FFADO is fine.

Anyway, I keep forgetting that some people still have computers that can do firewire and don’t have access to ALSA drivers in 2019. I didn’t even consider that you don’t have access to this when I started commenting. Sorry.

In-depth understanding of Jack and Latency measurement:

There are 2 versions of Jack. JACK1 and JACK2: https://github.com/jackaudio/jackaudio.github.com/wiki/Q_difference_jack1_jack2

JACK1 has a version number looking like 0.9.xx
JACK2 has a version number looking line 1.9.xx

To figure out the version u are using, type in a terminal:
jackd --version

There are 3 different latency measurement tools for Jack:

  1. jdelay : the original dsp. Shows the latency result only in frames (samples)
  2. jack_delay: it is packaged with JACK2. It shows the latency result in frames and in milliseconds.
  3. jack_iodelay: it is packaged with JACK1. It shows the latency in frames, in milliseconds and gives the values for the latency compensation (-I and -O arguments for Jack)

Jack_iodelay Manpage: https://www.systutorials.com/docs/linux/man/1-jack_iodelay/

JACK2 has 2 modes: the asynchronous mode (started by default) and the synchronous mode (needed to be started with -S):
If you are using JACK2 and didn’t start it explicitly with sync mode (-S), then you are using it in async mode.

HOW TO figure out -I and -O values out of the latency mesurement in frames (samples):

JACK1 and JACK2 sync mode has the same buffer latency, while JACK2 async mode adds 1 latency period more.

  1. Calculate the full buffer size.
  • for JACK1 and JACK2 sync mode: n*p. aka frames/period * period/buffer
    In my case: 1024 frames * 2 periods = 2048 frames (full buffer size for jack1 or jack2 sync mode)

  • for JACK2 async mode: (n*p)+1n. aka frames/period * period/buffer + 1xframes/period
    In my case: 1024 frames * 2 + 1024 frames = 3072 (full buffer size for jack2 async mode)

It is also possible to get latency information with the jack_lsp -l command instead of calculating it. This also includes sync/async mode settings of JACK2.

  1. Substract the full buffer size from the full roundtrip latency (measured by jdelay, jack_delay or jack_iodelay). Then divide by 2 to get -I and -O arguments.
  • In my case, if I use JACK1 or JACK2 sync mode:
    4414 roundtrip latency - 2048 = 2366 frames.
    -I and -O = 1183

  • In my case for JACK2 async mode:
    4414 roundtrip latency - 3072 = 1342 frames.
    -I and -O = 671


To calculates milliseconds, just divide the frames by your sample rate (in kHz).
Example: 1024 frames / 44.1kHz = 23.22 ms

You can put -I and -O also easily in qjackctl under:
Setup -> Advanced -> Latency I/O

  1. Make a test with Ardour.
  • Record Ardour’s click on a reference track and the same click through the full roundtrip loop.
  • Measure the latency with the selection tool.
  • It should be as close as possible to the reference click track (on the picture below I achieved to have it at 12 samples only!)

I hope all this helps!

PS: See the posts below for more information!

Not quite – the original, upstream version is jack_delay – jack_iodelay is an older version of it that was forked to be shipped with both jack1 and jack2 and also does some basic division by two to show -I, -O params.

In any case I don’t think the history of the project matters at all when you want to calibrate latency.

I suggest to simply look up the port-latencies that jack sets jack_lsp -l instead of calculating the nominal buffersizes. It also includes sync/async mode settings. – also note however that you should start jack with -I0 -O0 to perform the calibration.

so about 1.75 meters. Why does this not show up in your initial calibration measurement?

Why don’t you use thethe loopback cable where you don’t have any additional latency to show that after calibration, re-recording the same signal aligns perfectly (+/- 1 sample)?

jackd does not allow to set systemic latencies while the device is running, and most for most USB devices the linux kernel-driver add some random systemic latency (internal buffering) every time the device is re-started. So with JACK and USB devices you can not usually get accurate alignment. – This is however USB specific (and the reason Ardour/ALSA allows to configure systemic latency without device restart).

Hello Robin,
thank you for the information and the improvements!
I updated the post so your input is in and changed the screenshot with a better result (using the loopback cable). And yes, you were completely right, the microphones were about 1.75 meter away from the speakers! :slight_smile:

Last question: Does jack_iodelay knows about the JACK2 sync/async modes or it is just giving the JACK1/JACKsync values for -I and -O?

1 Like

Yes jack takes sync/async mode as well as number of periods into account when setting the output port latency.

jack_iodelay also informs you about this when port-connections change. Look for new…latency messages. Here jack2 in async mode, 2 periods, 1024 fpp. When connecting it to system:playback/capture it shows:

new capture latency: [1024, 1024]
new playback latency: [2048, 2048]

Note however that any previously configured -I, -O options will also be included here. Make sure to set systemic latency to zero when performing the measurement!