Unwanted record delay on vocals

26 replies [Last post]
audiodef
User offline. Last seen 5 days 2 hours ago. Offline
Joined: 2009-08-29
Posts:

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?

audiodef
User offline. Last seen 5 days 2 hours ago. Offline
Joined: 2009-08-29
Posts:

There seems to be a delay with everything, actually (we need an edit post function!)

joegiampaoli
joegiampaoli's picture
User offline. Last seen 23 weeks 2 days ago. Offline
Joined: 2008-02-27
Posts:

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.

dsyd
User offline. Last seen 4 years 31 weeks ago. Offline
Joined: 2009-05-03
Posts:

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

audiodef
User offline. Last seen 5 days 2 hours ago. Offline
Joined: 2009-08-29
Posts:

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.

peder
User offline. Last seen 49 weeks 3 days ago. Offline
Joined: 2007-05-08
Posts:

dsyd, I think the discrepancies are due to Ardour displaying round-trip latency and Jack only displaying input

dsyd
User offline. Last seen 4 years 31 weeks ago. Offline
Joined: 2009-05-03
Posts:

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.

Seb
Seb's picture
User offline. Last seen 11 hours 3 min ago. Offline
Joined: 2006-04-07
Posts:

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.

dsyd
User offline. Last seen 4 years 31 weeks ago. Offline
Joined: 2009-05-03
Posts:

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.

nickmurtagh
User offline. Last seen 1 year 15 weeks ago. Offline
Joined: 2007-01-22
Posts:

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.

audiodef
User offline. Last seen 5 days 2 hours ago. Offline
Joined: 2009-08-29
Posts:

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.

nickmurtagh
User offline. Last seen 1 year 15 weeks ago. Offline
Joined: 2007-01-22
Posts:

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:

1. Create a new session in ardour
2. Add two mono tracks
3. Import a piece of audio with a well defined transient such as a drum sample onto one track
4. Configure this track to output on your soundcard's first output
5. Connect output 1 of your soundcard to input 1 with a cable
6. Configure the second mono track to record from input 1
7. Record while playing back the drum sample

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

8. Tweak the jack input latency and repeat step 7 until the two samples are in sync

audiodef
User offline. Last seen 5 days 2 hours ago. Offline
Joined: 2009-08-29
Posts:

Thanks, Nick.

If anyone knows about the playback problem, I will seriously kiss boots! ;-)

roaldz
User offline. Last seen 1 year 39 weeks ago. Offline
Joined: 2008-11-12
Posts:

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

dsyd
User offline. Last seen 4 years 31 weeks ago. Offline
Joined: 2009-05-03
Posts:

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.

nickmurtagh
User offline. Last seen 1 year 15 weeks ago. Offline
Joined: 2007-01-22
Posts:

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

Pablo Fernández
User offline. Last seen 50 weeks 5 days ago. Offline
Joined: 2007-02-20
Posts:

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

dsyd
User offline. Last seen 4 years 31 weeks ago. Offline
Joined: 2009-05-03
Posts:

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

Pablo Fernández
User offline. Last seen 50 weeks 5 days ago. Offline
Joined: 2007-02-20
Posts:

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.

dsyd
User offline. Last seen 4 years 31 weeks ago. Offline
Joined: 2009-05-03
Posts:

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"?

nickmurtagh
User offline. Last seen 1 year 15 weeks ago. Offline
Joined: 2007-01-22
Posts:

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.

dsyd
User offline. Last seen 4 years 31 weeks ago. Offline
Joined: 2009-05-03
Posts:

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

Thanks.

Pablo Fernández
User offline. Last seen 50 weeks 5 days ago. Offline
Joined: 2007-02-20
Posts:

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.

Regards, Pablo.

screwtop
User offline. Last seen 2 years 29 weeks ago. Offline
Joined: 2007-01-31
Posts:

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.

Naturally I'm also noticing Issue 2798 quite a bit while doing this! ;)
http://tracker.ardour.org/view.php?id=2798

Regards, Chris.

DrG
User offline. Last seen 4 years 21 weeks ago. Offline
Joined: 2008-01-05
Posts:

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.

screwtop
User offline. Last seen 2 years 29 weeks ago. Offline
Joined: 2007-01-31
Posts:

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

screwtop
User offline. Last seen 2 years 29 weeks ago. Offline
Joined: 2007-01-31
Posts:

I have filed a bug report on this at

http://tracker.ardour.org/view.php?id=2878