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
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.
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.
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
@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.
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.
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
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.