Hi! I have been doing some tests in ardour 2.8.2. With two soundcards (UCA202 and m-audio 2496) at different period sizes, at different periods per buffer and at different sample rates. I also think nickmurtagh is right. I have observed that, when capturing finger taps on a mic while listening to the ardour click (not very precise method but anyway), ardour automatically compensates one period size plus the input latency introduced in jack. This value (period size + input latency) is what jack_delay shows at start, first line, as “capture latency”. (Note that the ubuntu jaunty package jdelay doesn’t show this, but “the real” jack_delay from Fons Andriensen site does).
So, I also think that this “input latency” value should always be the real round trip latency minus one period size, regardless of the rest of the settings and even your hardware. (Assuming jack_delay is correctly used and doesn’t print “??” or “Inv”, which I have sometimes observed when I close the loop through some hardware gear). Or, if you leave the default zero input latency, you should nudge backwards this number of frames after capturing.
I have also observed that “stop and start” qjackctl doesn’t always work when changing the input latency value, at least jack_delay didn’t print what I expected. It seems that you have to quit qjackctl and start again after changing this setting. This is jackd 0.116.1 with qjackctl 0.3.4.
@nickmurtagh: I have checked that 12288 works, though my ears are not that sensitive so there could be a very small amount of delay which I didn’t notice - I didn’t zoom right in to check for definite, as I was satisfied with the result I had got. It is possible the additional latency comes from hardware e.g. amps/speakers and mic placement. I think you are right when you say the correct value for input latency is not roundtrip/2 but rather the jack_delay value minus the capture port latency.
dsyd: jack_lsp -l shows me a port latency of 4096 for the playback ports but this is not the correct value for me - I need 4160 to get accurate latency compensation. So something is causing an extra 64 frames of latency. Have you checked that 12288 really works for you? Try my method of re-recording some material with a heavy transient into ardour and check at a high zoom level that the peaks match up.
roaldz: jack_delay (is this the program you meant?) gives me 8255.715 frames. It seems the correct value for input latency is roundtrip latency (from jack_delay) - frames/period. eg 8256 - 4096 -> 4160. I have verified this formula at 2048 frames/period as well. It is NOT roundtrip / 2, on my soundcard anyway.
I’ve been having similar problems recently with recorded material not aligning with existing material in a session. Previously, I’d set the input and output latency for jack and it seemed to work fine across a variety of period sizes. I was very happy: I’d never managed to get completely consistent sync like that under Windows on the same hardware! I was using 66 frames for both the input and output latency, having measured the total additional latency at about 131 frames at 44.1 kHz using an analog loopback on my sound hardware.
Recently I’ve done the analog looback test again and the latency now varies with the JACK frames-per-period (-pFPP) setting. I’ve used 2 periods per buffer (-n2) throughout, and 44.1 kHz sampling rate.
With jackd-0.116.2, jack_delay reports a delay of FPP x 2 + 131 frames. A multi-track analog loopback test in Ardour shows a delay of FPP + 131 frames.
With JACK2 (1.9.2), jack_delay reports FPP x 3 + 131 frames, and the Ardour loopback session shows new tracks lagging by FPP x 2 + 131 frames.
(The 131-frame constant varies between 131 and 135 frames, depending on which combination of inputs and outputs I use (I have an Echo Gina24 PCI with a Behringer ADA8000 chained onto it via ADAT), but is quite stable for any given configuration. “jack_lsp -l” shows the expected value (same as FPP) for the audio I/O port latencies.)
So, shouldn’t Ardour be compensating for the primary latency due to the period size? And why are the latencies different depending on which JACK version I use? Also, I noted that only the JACK input latency setting seems to compensate for this; changing the output latency seems to have no effect on the delays observed in the loopback test in Ardour.
There’s another thread on this in the forum somewhere. The gist is that Ardour/JACK can compensate for the software latency (number of buffers, size of buffers, sample rate) but there is no way on earth it can compensate for hardware latency because it has no way to measure it - unless you use jdelay and configure the input/output latencies in QJackCtl.
There is always going to be a measureable hardware latency with an extrenal sound card so you need to measure it and then configure the appropriate settings.
Secondly if you’re overdubbing, bear in mind that what you are recording is shifted out of sync by the round trip latency (software + hardware) so your recorded overdub will almost certainly be out of sync. I’m not sure how Jack or Ardour handle this but I’ve noticed things being out of sync in this case. For my part, it all gets too complicated and I just run Jack with 0.8ms latency and everything’s dandy.
Thanks DrG. I realise the hardware latency is a component of the total latency observed in the analog loopback test, and that JACK cannot detect it, but it does seem that Ardour is not (but could/should be) compensating for the output latency due to the software buffers, since the delay that I’m seeing changes predictably with p (frames per period) and n (periods per buffer). I would think that the only recording delays that would ideally be seen in a multi-track play/record loopback test would be the hardware latency, which could then be adjusted for in jackd’s -I and -O.
In a nutshell, I’m consistently seeing (n - 1) x p + I + O frames of delay on tracks recorded via analog loopback, which makes me suspect that Ardour isn’t adjusting for the output latency (of the source track) reported by jackd, the output latency being of course (n - 1) x p. The fact that changing the -O value in jackd has no effect seems to be further evidence that Ardour is not compensating for output latency.
It may be that I just don’t fully understand how the buffering works between Ardour, JACK, ALSA, and the audio hardware, or maybe something weird is going on with my system, but I’d like to know if this actually is a bug, as dsyd and nickmurtagh (and I) suspect. Has anyone filed it as such with the tracker? I’ve also had some feedback so far from Paul on this issue at: http://ardour.org/node/3077
Can anyone tell me where in the menus of Ardour 6 I can set the offset value ( in ms) for correcting recording latency Just like all DAW software has thuis option n main preferences.
I run Ardour on W10 and don’t use Jack.
I would like to compensate for 80ms.
Thanks and regards, Hans
Hi Robin Great, thanks so far. Latency might be caused by my audio interface Beringer UMC204HD, which I also use for hardware monitoring. So this 80ms is the whole chain.
Maybe changing USB port can lower. Or my buffering is on the safe side. I record over 30 tracks for one project. If compensated 80ms is not a big issue. I 'll also check the Asio. Ardour is new for me. I ll look into this futher this weekend. I ll keep you informed. Grtz Hans
I record over 30 tracks for one project. If compensated 80ms is not a big issue. I 'll also check the Asio. Ardour is new for me. I ll look into this futher this weekend. I ll keep you informed. Grtz Hans