Hey all,
Just a quick question about timing in Ardour. I’ve noticed most of the time when I record there is a slight (like half of a second or less) of delay when I play it back with the other tracks. It isn’t much but just enough to notice it isn’t quite like I recorded it. Any idea what could be causing this?
Thank,
Jamie
Hi Jamie,
I seem to be having similar problems. Does the delay get worse if you use a larger value for the period size in JACK? Or better if you decrease it?
As I understand it, JACK and Ardour go to considerable lengths to account and adjust for latency, so this sort of thing probably shouldn’t be happening. These forum threads may be discussing the same issue:
http://ardour.org/node/2929
http://ardour.org/node/3077
Cheers,
Chris
Thanks for the reply screwtop. Following the information in the “http://ardour.org/node/2929” thread, I’ve used “jdelay” to fix my problem (I think). Jdelay gave me a number of about 4428 which I divided by two so I put 2214 in for input delay in qjackctl and I also put 2214 in for output delay in qjackctl.
Was I supposed to put half in input and the other half in output like that or just in the input delay?
I does seem to have fixed my “lag” issue, I just want to be sure I’m doing it right.
Thanks,
Jamie
Edited for corrections, 2009-10-23 18:53 NZDT (emphasised)
If it’s the same problem I’m seeing (I’m assuming you’re using Ardour 2.8.3), you can work around the delay by using just the extra input latency to compensate. Don’t worry about the output latency - it won’t have any effect on the alignment of new tracks at present - or the half-and-half thing. Just set the extra input latency to the round-trip value reported by jdelay/jack_delay minus the JACK period size. It’s not normally supposed to work this way - this is just a workaround for what seems to be a bug in Ardour.
What are you using for frame size and number of periods, BTW? You’ll find that to get correct sync, you’ll have to change the extra input latency if you change the frame size or number of periods in JACK. Again, this is not the way it’s supposed to work, but for now, just be aware.
If you want to test that it’s worked, you can re-use your loopback cable setup with an Ardour session. Play an existing track out through the loopback and record it back into the session. You can then measure the exact delay by looking at the waveforms on the timeline. Ideally, they’ll match up exactly.
Hope this helps. 
Okay, so put 4428 (or whatever jdelay gives) in input latency and nothing in output?
I have frames set to 512 & periods to 3. I’m using Linux and Ardour 2.8.3.
I use a GNX4 for all my recording which seems to work like an external sound card. I read somewhere that periods on USB soundcards should be set to 3 instead of 2. I don’t have any xruns at all with my setup (unless I “close” totem, and then it’s just one xrun).
Edited for corrections, 2009-10-23 18:55 NZDT (emphasised)
Yep, just use jdelay’s round-trip number minus the period size in the JACK input latency (both measured in frames). The current issue with output latency is that Ardour’s recording point is ahead of where it should be, by the output latency. This cancels out Ardour’s own output latency compensation! I’ve spent a few days trying to figure it out, but it’s looking like a bug.
For lowest latency, use the smallest period size and number of periods that work on your system. 3 periods minimum for USB is normal I think; I have a Firewire box that also won’t work below 3. I think occasional xruns when connecting/disconnecting programs from JACK are normal. Let me know how you go.
Thanks screwtop, you help me out here big time buddy :oD!
I played around with it a bit more tonight and I got the “>> Inv” I was also getting out of it and my “accurate” (as far as I know) round trip number is 2190 which I put in qjackctl’s “input latency” and left “output latency” as 0 (it reads default).
I did a bunch of tests and my recording is to the “beat” accurate as near as I can tell. It used to seem to start recording just a half a beat or less after where I wanted it and I was having to “slide” it to where it needed to be. Putting that input latency in seems to have fixed it perfectly.
On the “frames/period” in jack… I’ve taken it down to 64 with a “periods/buffer” of 3 and got a stable 4.35 m/s latency but for what I’m doing I could see no real difference so I just leave “frames/period” at 512 with a “periods/buffer” of 3 and get a 34.8 m/s latency. It works well enough.
Oh, thanks for the bug report too.
Glad to help. I’m going to try to write some stuff about this for an FAQ, I think.
If you get “Inv” from jdelay only occasionally, it’s just a glitch in your audio signal chain. If you get it for every reading, and everything else seems consistent, it means that either the input or output of your audio hardware inverts the signal. Mine does this, BTW. It shouldn’t make an audible difference unless you’re combining sounds processed through your computer with other sounds that are not being inverted, in which case you may get some (or much!) cancellation unless you invert the polarity again in the computer to compensate.
Actually, setting the latency really low is only necessary if you’re doing real-time interactive things, like using a software synthesizer, that need an immediate response. For multi-track recording, Ardour is supposed to compensate for the latency due to the ALSA buffer settings (i.e. period size and count) and other known latencies (e.g. in certain plugins). The only difference you’d see due to bigger buffers would be some extra milliseconds delay in the transport rolling after you click Play. In the current version, though, the latency compensation is apparently not working.
The jdelay loopback test will report a smaller latency with smaller buffers, but 3 x 64 is probably as small as you’ll be able to go on your hardware. Higher sampling rates mean lower latency when measured in ms, because the frames in the buffer are processed faster.
When Ardour’s latency compensation gets fixed, you would calculate the extra input and output latency as follows, for the settings you mentioned:
2190 frames round-trip latency - 3 x 512 frames software buffering latency = 654 frames hardware buffering latency
The hardware buffer is in your sound card, and JACK doesn’t know how big it is. You can generally assume that the hardware input and output latency would be about equal, so you’d divide 654 frames by 2 and set the input and output latency each to 327 frames. With a loopback test, you can’t really measure just one or the other!
(Come to think of it, 327 frames input and output latency seems a little high to me - perhaps being a USB device there is more latency.)
Correction: what we’re doing here (for the sync problem in Ardour 2.8.3 and perhaps some earlier versions) is basically fudging JACK’s extra input latency to compensate for the hardware input and output latencies and the software output latency, but not the software input latency, which the current Ardour does compensate for correctly. (I forgot about the software input latency before.) The input latency is simply the length of one period, i.e. it’s the period size in frames. So, in your case, with 2190 frames round-trip reported by jdelay and 3 x 512-frame periods in JACK, the extra input latency would be calculated as follows:
2190 frames - 512 frames = 1678 frames extra input latency (workaround for Ardour 2.8.3)
(Again, the value you use for extra output latency won’t have any effect on multi-track sync in Ardour 2.8.3.)
Sorry for any confusion! Could you try that with a click track through analog loopback and check that the overdub lines up exactly?
Okay… if I’m doing this right?
I recorded Ardour’s “click” track into my first track in Ardour. Then (on my GNX4), I took the “output” jack into the “input” jack. I recorded that. With no input latency put in qjackctl, the new recorded track was a little “late” with the original track. Then I tried my initial number of “2190” and the new track was slightly “ahead” of the original track? I tried your formula of “2190 frames - 512 frames = 1678” and used “1678” and it was right on the money with the original track.
So “1678” seems to be right.
Again screwtop, I can’t thank you enough ;o).
Thanks for all your information , I learned a lot from both of you, I seem to be having similar problems.
[url=http://www.comfortinnovations.com.au/young_shower_screens/frameless_shower_screens[/url]
I think I’m missing something. I’m trying to use jack_delay to get an input latency because there’s a bit of a delay on playback, which will mess me up when recording new tracks while listening to old ones. With frames/period set to 2048 (below that, I get xruns), jack_delay gives me 42.667 ms. I’m sure I’m reading the above instructions wrong because value reported by jack_delay minus the jack period size is a large negative number.
What am I missing? I ran jack_delay in a terminal and connected jack_delay’s out to jack_delay’s in (a closed loop, right) in qjackctl. Out comes the number 42.667 until I hit ctrl-C to stop it.