Quick question about starting jack independently

Does Ardour use the values supplied to jack using the -I and -O command line parameters to make latency calculations? or does Ardour do the calculations by it self?

I had a scan through the code on github and there is so much of it (hats off to the devs for working so hard) that I can see the audio engine code and that it is doing some latency related things but I am really looking to find out if starting jack manually and not letting Ardour start jack means that parts of the audio engine which handle latency are bypassed or if the values supplied to jack to compensate for round trip latency are ignored and Ardour does a calibration on it’s own?

Any insight into this would be very helpful.
Thanks

When ardour starts jack it just passes the -I and -O parameters to jackd.

WRT to latency-compensation, there is no difference starting jackd externally or letting Ardour start it. Once running, Ardour only cares about port latency (jack_lsp -l).
The built-in “Calibrate Latency” button in the engine dialog is just a wrapper around fons’ jack_delay to measure it and determine values for -I and -O.

Thanks x42!

I am asking because I am running Ardour from git master and I have a -0.1 millisecond amount of latency on the record track when doing a loop back test.
I am trying to work out if there is something I can do to adjust for it or if it is a bug.
I tried the track latency adjustment and it does not seem to add any latency at all.

Any suggestions?

that sounds like the -I and -O values given to jack are too large.

For some soundcards, esp USB ones, the systemic latency differers depending on period-size and I’ve also seen cases where it varies a small amount every time jack is re-started. What soundcard are you using?

But really 0.1 msec that is ~5 samples at 48K or 3cm of sound in air. I expect that’s far above average :slight_smile:

I have a spreadsheet I made here to do all the maths involved. The problem might be that the total extra loop back latency is 40 according to jack_iodelay and thus 20 for -I and -O. But jack_iodelay is rounding down. The actual total loop back latency in frames is according to my spreadsheet is 40.919 frames. This is calculated from 472.919 frames of total round trip latency.

/usr/bin/jackd -p512 -t2000 -cs -dalsa -dhw:PCH,0 -r48000 -p144 -n2 -H -M -i2 -o2 -I20 -O20 &> /dev/null &

jack_lsp -l
system:capture_1
port latency = 164 frames
port playback latency = [ 0 0 ] frames
port capture latency = [ 164 164 ] frames
system:capture_2
port latency = 164 frames
port playback latency = [ 0 0 ] frames
port capture latency = [ 164 164 ] frames
system:playback_1
port latency = 308 frames
port playback latency = [ 308 308 ] frames
port capture latency = [ 0 0 ] frames
system:playback_2
port latency = 308 frames
port playback latency = [ 308 308 ] frames
port capture latency = [ 0 0 ] frames

cat /proc/asound/cards
1 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xfe720000 irq 52
2 [HDMI ]: HDA-Intel - HDA ATI HDMI
HDA ATI HDMI at 0xfe660000 irq 53
8 [LPK25 ]: USB-Audio - LPK25
AKAI professional LLC LPK25 at usb-0000:00:1a.0-1.2, full speed
9 [LPD8 ]: USB-Audio - LPD8
AKAI professional LLC LPD8 at usb-0000:00:1a.0-1.6, full speed

Ardour44.0.rc2.22 (built using 4.0-rc2-22-ga8d9014 and GCC version 4.8.3 20140911 (Red Hat 4.8.3-7))

jackdmp 1.9.10

I will try a higher number of frames per period but I expect the result to be the same.
Getting within .01 of a millisecond when doing a loop back test is pretty good but I am sure there is some way to get it exact because I can get it exact in Audacity.

Any idea if manual adjustment of latency is broken in the master git branch for Ardour?

It is not broken and I absolutely do NOT believe you can do better with Audacity. Convince me.

Hi paul, x42, I disconnected all of the jack connections and manually connected each one. Then I replaced the audio cables I was using and the issue has now been fixed. :slight_smile:

I made a screen capture of some quirks I found in the adjust latency menu.
https://drive.google.com/file/d/0B45Yi_r5mamwWUcyWFJKRXlsejQ/view?usp=sharing
If any one can confirm any of the issues I can see, then I can report them on the bug tracker if you like.

I am seeing :

  • The adjust latency menu does not update the unit of measure above the drop down - after it has been selected. Until you press the + increment button.
  • The latency amount does not visually reset when the reset button is pressed (although closing and re-opening the menu confirms that the value has been reset.)
  • The latency amount input box displays 1.000000000 when manually selected using the mouse. Regardless of the unit of measure or any value which has been previously set.
I wonder if adjustment using negative values is supposed to be possible using the adjust latency menu? Because the minus button will not allow the value to go lower than 0 and manually entering say -1 resets the input box to 0 (Not yet implemented?) If I select 10msec of latency to add to a channel and then record into that channel, no additional latency is visually added to the recorded track (I am unsure if this is by design.) I have not tested further by rendering an output and comparing original vs recorded.

TLDR; I can no longer reproduce a problem I had with loop back through Ardour but I may have found issues in the adjust latency menu in the process.

We do not ever show latency visually. It would be completely counter-productive.

So are you saying that if Ardour were to maintain track or track segment positions relative to any per-track latency adjustments on the timeline, it would be a bad idea?
If I understand correctly you are making the assertion that using your eyes instead of your ears when working with sound is counter-productive. I agree with that sentiment.
I am referring to the position of the audio on the timeline in relative position to latency added to the beginning of a track. I am a little concerned with a visual representation of latency.
I am however interested in the notion that data on a track on the timeline could be synchronised audibly and visually according to any latency additions or subtractions.