I just recorded some vocals in Ardour and there seems to be a delay upon playback. I had to move the vocal region back a little so it synced with the rest of the composition.
Why did this happen and how do I fix it? Could this be a jack problem rather than an Ardour problem?
Nick, thanks for the tip on setting the input latency. I can’t test it right now, but I’ll post how I get on later.
It seems strange that manually compensating for the input latency should be necessary though, because Ardour is able to calculate the correct latency value in the “Audio settings” tab, even though it uses the incorrect latency value (i.e., the latency for a single period, rather than multiplied by the actual number of periods) when it actually does the recording.
i did a similar experiment to dysd a while ago and it compensated near-perfectly over a wide range of periods and 2 or 3 bufffers. (actually the recording ended up a tiny margin ahead of time compared to the source).
But recently, i did notice a time-lag when overdubbing vocals. Maybe a regression bug.
I have just tested Ardour 2.8.2 rev 5396, Ardour 2.8.2 rev 5595, Ardour 2.8.2 rev 5637 and Ardour 3.0 rev 5637. All have the same latency compensation problem, so I presume it is not an Ardour bug. I’ll try some different Jack versions next.
It seems that Ardour is only compensating for the input latency, and not the round-trip latency. Both “Align with capture time” and “Align with existing material” seem to always align in the same place.
I currently have FPP set to 4096 and BPP set to 4. Output of “jack_lsp -l” gives:
system:capture_1
port latency = 4096 frames
system:capture_2
port latency = 4096 frames
system:capture_3
port latency = 4096 frames
system:capture_4
port latency = 4096 frames
system:playback_1
port latency = 12288 frames
system:playback_2
port latency = 12288 frames
This looks correct. I can get Ardour to align correctly by manually adding the output latency to the input latency, i.e. by putting 12288 into QJackCtl’s “Input Latency” box, as suggested by Nick.
Is this correct behaviour, and if not, what could be the reason why Ardour is compensating for the input latency but not the output latency, even when tracks are set to “Align with existing material”?
Hi, the 4160 is specific to my setup and is unlikely to work for you. To work it out you need to do something like this:
You should now have a new recording of the drum sample on the 2nd track but it’ll probably be out of sync with the original sample
Thanks, Nick.
If anyone knows about the playback problem, I will seriously kiss boots! 
Sure,
Box 1 is ardour 2.7.1 built from revision 4296 and box 2 is ardour 2.8.2 from rev 5396.
Sorry murtagh, maybe it’s me who needs to update.
Cheers, Pablo.
@Pablo: Thanks for the info and for confirming this. Please could you post the revision numbers for each of your Ardour versions (from Help->About). The reason I ask is that I am using Ardour 2.8.2 already (rev 5595).
I’ll try testing some other versions of Ardour on my setup when I get a chance and report if I can find which versions are/are not affected.
There´s a much better way for measuring latency. You should use Jdelay. It produces a test signal, which you have to loop from the output of your soundcard to the input of your soundcard, back to jdelay.
It spits out the measured latency in samples (so it is samplerate-dependent). This is round-trip latency (time to get out + time to get in). So this is probably twice as much as your input/output latency, so split it in half, roundoff down, and fill in the input/output latency boxes in qjackctl (or the -I and -O commandline option).
https://help.ubuntu.com/community/UbuntuStudio/Record_Now_with_FireWire
@nickmurtagh: I have done the click test, also recording a cowbell through hydrogen.
Box number 1: jack --version is 0.116.1 ardour version is 2.7.1. distro: Linux Mint 7
(ubuntu jaunty for this matter).
Box number 2: jack --version is 0.116.1 ardour version is 2.8.2. distro: Ubuntu jaunty,
ardour from somewhere else.
In box 1, the click or cowbell are recorded as you describe and there are different off-sets with different
n values (PPB ).
In box 2 they are recorded just in the right place, disregarding the n value and the source (ardour click or hydrogen).
If ardour is very important for you, take the time and update!
I think roaldz post is the one to follow. Although I have some doubts, this time I will try to prepare the question before I ask, if there are still doubts after that.
Thanks to all for this interesting thread. Regards. Pablo.
dysd: yeah I think it’s a bug. I’ve been using the same setup (RME HDSP + jack + ardour) for years albeit with different distributions and kernel versions and I definitely didn’t need to worry about jack input latency until recently (maybe a year or two). Also, at some point this year I had to re-calculate the input latency because the value I had been using stopped working - presumably due to a jack upgrade.
roaldz: thanks for the tip, I’ll give JDelay a shot and see how it compares to my method
I’ve noticed this as well. In qjackctl setup you can specify an input latency. I have mine set to 4160 (samples) and recorded audio is now in the right place. You can test by setting up a click track and then recording it within ardour. If the playback of the recorded click track doesn’t line up with the built in metronome then the input latency is wrong. I don’t know if this is a bug as such, but it’s pretty easy to work around using the above mechanism. A proper guide to setting input (and output?) latency from the devs would be welcome!
Once you work out what your input latency is for your own setup, you can fix existing sessions by setting the nudge amount to the appropriate value (right click on the nudge input box to choose “samples” as the unit) and move the wrongly placed audio back using the nudge facility.
It seemed to record some drums from a synth workstation right on beat after some changed to my jack settings, but now what’s happening is every now and then playback drags and I get that low eeeeehhhh noise for a second. This is happens more often when I start patching sends to buses.
Right now I have jack set to 64 frames/period, 48kHz, 6 periods/buffer. I just added 4160 for input latency, but haven’t tested that with vocals yet. At the moment I’m having the playback problem I just described.
Hmm, well I’m using Ardour 2.8.2 rev 5595, jackd 0.116.2. I don’t think there is much special with my setup except for it being 64bit and without a realtime kernel.
I’d be interested to know if it is just myself and audiodef, or if others have the same alignment issues (though perhaps haven’t noticed if they are running a low-latency realtime setup).
@seb: Interesting, I assume you were testing very high latencies with large buffer sizes?
@audiodef: Interested to know the results of your tests, cheers.
dsyd, that’s very interesting. Thanks for sharing that. I’m going to experiment with jack settings and see what Ardour does. I’ll post what I find.
Joe: Gentoo, Gnome 2.26.3, kernel 2.6.30, Dell Dimension 5510, two Mackie Onyx mixers with Firewire.
I think this is an issue between jack and Ardour, as dsyd pointed out.
dsyd, I think the discrepancies are due to Ardour displaying round-trip latency and Jack only displaying input
peder, I am not exactly sure what you mean by “round-trip latency”. There is only a single connection, from the system capture port to the Ardour track input. I am using hardware monitoring, if that is what you mean, so I do not have a problem there, the only problem is with the Ardour alignment. In order to determine the values above, I simply turned the click track on, recorded, and measured the offset between the grid beat and the recorded click.
Whatever I set the buffers per period option to be, Jack always reports the same latency value for a single buffer per period, i.e.:
configuring for 48000Hz, period = 4096 frames (85.3 ms), buffer = [PPB] periods
Ardour does not multiply this figure by the number of buffers per period to get the correct latency. For example, if I set FPP to 4096 and PPB to 2, Ardour will report 85.3ms as the latency (at the right of the menu bar), half of the actual latency to get audio from my mic into Ardour’s track input. If I then set PPB to 16 and keep FPP at 4096, Ardour will still say the same latency of 85.3ms, despite the fact that the input latency has gone up 8 times. I.e., Ardour (at least with my setup) only ever compensates for a single period per buffer, meaning the audio is offset by the remaining [PPB]-1 periods.
Ardour should compensate for any latency, but I have noticed that on my hardware (Lexicon Omega using Alsa’s USB drivers) the alignment changes depending on my Jack settings. I did some tests, keeping my latency at a constant of 341 ms, each time doubling the periods per buffer and halving the frames per period. I get the following approximate alignment errors:
FPP: 8192, PPB: 2, Alignment error: 174 ms
FPP: 4096, PPB: 4, Alignment error: 259 ms
FPP: 2048, PPB: 8, Alignment error: 300 ms
FPP: 1024, PPB: 16, Alignment error: 318 ms
It is interesting to note that the alignment error is always equal to [(PPB-1)/(PPB)*Latency]. This suggests that Ardour or Jack is always calculating the latency assuming a PPB of 1, leaving all of the rest of the periods unaccounted for. If I could set it so that PPB was actually equal to 1, Ardour would be fully compensating for all of the latency; unfortunately I don’t think that is a possibility.
Also interesting to note is that when I start Ardour and go into the Audio Setup tab, with “Buffer Size” set to 8192 and “Number of Buffers” set to 2, Ardour correctly states “Approximate latency” as 341.3 msec. However, when I then open a project, I get this printed on the shell:
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:1,0|hw:1,0|8192|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 48000Hz, period = 8192 frames (170.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian
ALSA: use 2 periods for playback
It seems to be this 170.7ms figure which Ardour uses to compensate for the alignment of recordings, instead of the correct 341.3ms (=170.7ms per period * 2 periods).
Hmmmm, well it seems like you have a quite big latency issue there, please post what OS you are using, distro, kernel, hardware, etc, to help you out.
There seems to be a delay with everything, actually (we need an edit post function!)