Latency compensation in Ardour 2.8.12

8 replies [Last post]
PaulRH
User offline. Last seen 5 days 23 hours ago. Offline
Joined: 2010-04-18
Posts:

I am unclear what (if anything) I need to configure for latency compensation in 2.8.12. This is in the context of recording against playback of previously recorded tracks.

Would appreciate some enlightenment!

Thanks. Paul H

mcgruff
User offline. Last seen 1 year 3 weeks ago. Offline
Joined: 2008-08-30
Posts:

It's may be a good idea to set input/output latency in jack. If you're using qjackctl open the "setup" window and see bottom right. You can use jack_io_delay (from the comand line) to measure your interface's hardware latency in a loopback test. Connect an output to an input, run jack_io_delay, connect it up in the qjackctl "connections" tab, and then read off the results. More info here: http://ardour.org/node/4565.

paul
paul's picture
User offline. Last seen 3 hours 54 min ago. Offline
Joined: 2006-03-16
Posts:

you don't actually nede to configure anything to get things reasonably accurate BUT you do need to be running an up to date version of JACK. if you use JACK1, you should be using 0.121.3 and if you use JACK2, 1.9.8. Failure to use these versions will result in mis-alignment of material under some circumstances.

PaulRH
User offline. Last seen 5 days 23 hours ago. Offline
Joined: 2010-04-18
Posts:

Thanks mcgruff. I have already made some tests with jack_iodelay, and know what numbers I need to plug back into jack.

Is it the case that Ardour then does the compensation automatically, based on the latencies then reported by jack?

Paul H

paul
paul's picture
User offline. Last seen 3 hours 54 min ago. Offline
Joined: 2006-03-16
Posts:

@PaulRH: latency compensation is based on the numbers reported by JACK. Without you doing anything at all, these will be fairly accurate. But by itself JACK cannot know the delays caused by any analog/digital conversion. If you use jack_iodelay to determine these, then the numbers from JACK will be accurate to within 1 sample.

And yes, Ardour does all this stuff automatically. It will go wrong under one well-known circumstance: if you have a track connected to both a hardware input and another JACK client, Ardour has to make a choice about which latency to use. Whatever it choice it makes will be wrong in some cases. So if you ever use Ardour to record from other JACK clients rather than your audio interface, be sure to make sure that the track is disconnected from the audio interface.

PaulRH
User offline. Last seen 5 days 23 hours ago. Offline
Joined: 2010-04-18
Posts:

@Paul,

Thanks for clarifying this! The caveat is noted.

Paul H

froh
froh's picture
User offline. Last seen 26 weeks 3 days ago. Offline
Joined: 2006-10-18
Posts:

Ah, that explains why my Hydrogen track was slightly off after i recorded it in Ardour, passing through in a bus won't have the same effect on latency then i guess.

PaulRH
User offline. Last seen 5 days 23 hours ago. Offline
Joined: 2010-04-18
Posts:

Folks, can I just double check that I am understanding jack_delay correctly?

A - The periods/buffer (-n) parameter for jackd applies to playback only, and 1 period is buffered on capture.

B- That being the case, the contribution of jackd latency (in frames) to the total round-trip latency as reported by jack_delay should be:

jackd_round_trip_ latency = (n+1) * p

Where n is periods per buffer for playback and p is period size, frames/period.

C - The actual hardware latency (in frames) would therefore be:

hardware_latency = total_round_trip_latency - jackd_round_trip_latency.

and the -I and -O parameters for jackd would therefore be hardware_latency / 2 (all other things being equal).

Sorry to labour this issue, but would prefer to have a solid understanding of this before I go "tinkering".

Paul H

paul
paul's picture
User offline. Last seen 3 hours 54 min ago. Offline
Joined: 2006-03-16
Posts:

PaulRH: if you use a current version of JACK, the output of jack_iodelay has been updated to make this easier to understand. Your understanding is correct.