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:
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) ?
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).
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_iodelay comes in the same install package as jack 0.125
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.
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.
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.