Playback delay

I don’t know if I should configure JACK differently or what, but I can only work on a session for a few minutes before the vocals start playing back late to the piano. I can’t figure out if it has anything to do with the latency I’m running or my buffer sizes (I don’t really understand buffers, so I’m not sure how it could contribute or if it could). I’ve been running the highest latency possible, since I’m done tracking and am into mixing now. If I restart the program it typically (not always) fixes it, but it will just recur a few moments later with varying degrees of awfulness. I’m running Ardour 2.8.11 on an iMac with a 3.06 GHz dual core processor on OS X 10.6.5. I have done a few other sessions since installing with excellent results. I have only noticed the problem on one session, however that is the only session I have been working extensively on, so I can’t be sure whether the problem is universal or not.

One thing that is interesting is the piano was tracked in stereo, but when I brought the session into Ardour I brought it in as two mono piano tracks, and they never get off from each other.

I know I might be leaving out some important information that might help you guys understand the problem better, but I wouldn’t know what to post. Any ideas?

One thing that is interesting is the piano was tracked in stereo, but when I brought the session into Ardour I brought it in as two mono piano tracks, and they never get off from each other.

I know I might be leaving out some important information that might help you guys understand the problem better, but I wouldn’t know what to post. Any ideas?

From the sounds of your post, you sound like you are dealing with audio drift. From the sounds of the first quoted paragraph, it sounds like you tracked some of this material other than in Ardour, possibly on other machines or other audio interfaces. If this is the case it is not surprising.

When recording if you use mutliple digital audio equipment(Including interfaces) we use a master clock to keep everything in sync. Even though we may tell the hardware to run at 48kHz, in actuality the clock inside that hardware runs just above or below 48kHz, and this exact speed is different for each piece of hardware. A master clock forces each piece of hardware to use a single clock source to keep everything in sync.

A few samples difference here and there may not seem like much, but it makes a significant difference spread over a longer period, even as short as a few minutes(As you have noticed). Thus you need to make sure you don’t allow drift to happen.

Since you already have the recordings, your best bet is to trim your recordings to the very first and very last note of the music, then use Ardour’s time stretch tool to shrink the longer region down to match the shorter region. This will introduce artifacts in your recording sadly, but may well fix your problem.

It is concievable(Not likely but possible) that one of your plugins is introducing a drift as well, you can always try disabling all your plugins to check this, but chances are this is not the case. The more likely cause is what I mentioned above.

 Seablade

You are correct. I tracked this on a RADAR system at a different studio and brought it back to my home studio running Ardour. What precautions should I take next time if I plan to track on one system and port it to another system? Nothing was tracked at my studio at home by the way; it was all done in one session on the RADAR system. I had thought this would mean that the tracks should still all be on with each other. Am I wrong on that?

Also, I have yet to measure this, but it seems like only the vocal is off from everything else, and if it is off, it is off from the beginning to the end by the same amount. That’s what lead me to believe that it wasn’t drift. Visually, the playhead hits the wave at the right time where it should play, but the sound is actually coming out up to about a half second later (**Edit: I just measured it and the sound is delayed about a second and a half 12 seconds into the song. At 3:28 it is 2 seconds off. Again, the wave visually is aligned properly. I also measured around 2 seconds at 44 seconds, and then 2 seconds at 12 seconds again after it was a second and a half earlier). I’ve only noticed this on the vocal, and only once I started mixing and matching takes. I’ve disabled plugins, but it doesn’t seem to affect it much.

This is a very strange problem to me. Is there anything I can do with it in Ardour? Is this a bug, or can I change some configuration to fix it? This post (http://ardour.org/node/2929) seems to suggest there might be a bug in Ardour that may contribute to the problem? Should I just go mix it at the studio where I tracked it?

Hi benekastah,

You should definitely be able to import tracks from RADAR and have them stay in sync throughout the song.

I’d suggest that you create a new session, import the tracks, and listen back to verify sync of all tracks at the beginning, end & middle. If they don’t sync up at the beginning then you need to make sure they were started at the same time, and/or make sure that they are imported using the embedded timestamps and those timestamps are correct. If sync starts off right, but then drifts, I’d suspect you’ve got tracks that were recorded at different sample rates and somehow aren’t getting SRC’d to match the rate of the session. This could be because they were “outside” the RADAR machine, playing from a separately synced system; or maybe the RADAR session was used with an external clock that didn’t match the rate stored in the RADAR session file.

Once you’ve verified that the tracks are in sync, then you can start editing & mixing. Save off regular session “snapshots” so if the problem comes back, you can backtrack a few steps and determine which action caused the out-of-sync issue.

Good luck!

-Ben

Hmm…

That post would be about something different(General latency in the system affecting everything, not just one track).

If everything was recorded on a single system(More specifically a single clock or AD interface), you should not be getting this error certainly, and you would be the first one I know of to see such behavior if it wasn’t user error. And certainly the amount of time you are talking about lends itself to not being standard drift. I can’t think of anything that would cause the exact behavior you are talking about off hand, where the amount of delay shifts from a second and a half to two seconds depending on where in the track you are, but doesn’t continue to increase past 2 seconds. What I really would love to see is the output of a specific program on those files, but sadly it is something that would have to be compiled in order for you to use it on OS X as I can’t think of a precompiled version at th e moment.

Ar you importing(Copying files to the session) or just embedding(Links to the files elsewhere)? Is there any difference if you create a new session and reimport the tracks? I somehow doubt that will make a difference, but I just want to confirm there was nothing done before this that would cause this behavior. If the behavior is still there, can you get on IRC(Help>Chat in Ardour) and see if you can catch someone there(Myself included) to just run through a couple of things hopefully? Typically daytime EST is the best time to catch people, but sometimes you can get lucky other times as well.

   Seablade

Thanks for the response seablade and BenLoftis. I originally didn’t know how to import a RADAR session into Ardour, so I did it by hand (to answer your question seablade, I imported the files). I do remember that it was initially all in synch before I started mixing. But, does anyone know how to import a RADAR session into Ardour so I can try it again? That would save me a lot of time, and might somehow cause things to work better.

You might want to look at ArdourXchange and/or AATranslator.

Importing the wavefiles should be sufficient, though. RADAR is just a recorder, there isn’t any special metadata that needs to be imported to make the session usable.

Why not ask on the RADAR support forums/whatever? I’m sure those guys have a lot of experience importing RADAR sessions into DAWs.

-Ben

Thanks everyone for your responses. I found out the RADAR session imports nicely into REAPER! But, it turns out that Ardour rocks REAPER.

I’m pretty sure now that the delay is being introduced through (seemingly) any insert. Both piano tracks have an insert as well, which causes them to be slightly off the click track (much less delay than the vocal track), but since they have the same insert, they are off by the same amount, and I never noticed. I took the insert off the vocal track and it corrected the problem. I can figure out a compromise in the case of the vocal. I could compromise on the piano tracks as well by making an instance of the EQ plugin I’m using on each track instead of on a buss, but I wonder: why would inserts delay the sound? Since I don’t know much about setting up digital audio (esp. buffers and latency) and tend to use default settings until I see a problem, I wonder if there’s some configuration that may help. How do I determine what my latency/buffer settings should be while mixing? Maybe that’s not even the right question. Any ideas?

Which plugin / insert are you using which is causing the problem?

All the ones in that session. I haven’t noticed it in other sessions (but I mainly use sends in the other sessions I have been working on). The vocal was being routed via insert to a buss, which was in turn routed to the main reverb buss. The first bus acted mainly as a proxy of sorts so I could automate the reverb send. Then the two tracks that make up my stereo piano were inserted to a buss with a compression effect on it. When I removed the inserts and put the compression plugin on each piano track and stopped worrying about automating the reverb send from the proxy buss arrangement, the delay disappeared and everything was right on with the click track again. Weird (and yet awesome).

Edit: I just went to another session and for the sake of experimentation inserted a couple guitar tracks into a buss with a flanger on it. They got pretty off, about as much as what was described in my other posts. Sending the bass guitar to a bus with compression on it didn’t seem to create any problems, though. It seems like a bug to me…

It would be interesting to know some specifics e.g. exactly which flanger plugin are you using when you get the problem, or which reverb were you using, and perhaps some settings. If you can insert a compressor onto a buss and you don’t get the problem then there is unlikely to be a bug in ardour, but some effects or inserts do add their own latency, as part of their processing - and perhaps are incorrectly reporting this latency to ardour - all of which may cause the kind of problem you are experiencing.

benekastah,

“Inserts” are normally used to route audio out through your soundcard, into some external gear, and back into the track/bus. They have a built-in function called “measure latency” which will (in the case of a track) automatically calculate and compensate for the I/O delay.

I think you might be using the term “insert” when you mean “send”. This makes it hard for us to help you.

If you are, in fact, using an “insert” to insert a bus into your track, then I’d guess this is the source of your problems. You should use “sends” instead.

Be aware that Ardour compensates for plugin latency on the tracks, but when you get into complicated bus arrangements, with plugins on the buses, there is no guarantee that the signal will arrive at the same time as other signals. If you are going to use buses to generate 2 or more parallel paths for a signal, then here are some “best practices”:

  1. insert any “high latency” (such as lookahead limiters or Convolution/FFT-based ) plugins on the tracks (where they are compensated for) or the master bus (where it affects everything equally) - not buses.
  2. It is OK to use zero-latency plugins such as EQ’s and compressors on parallel buses
  3. If you send to a bus with a reverb or delay effect that is 100% wet, it is often OK to send to that bus from multiple buses because any latency inherent in the plugin will only add a slight delay to the reverb effect, it probably won’t be perceived as out-of-sync.

Note: Ardour3 should have complete delay compensation throughout. Similarly, Mixbus provides full delay compensation from tracks, through mixbuses, and to the master. ( note: I work for the developer of Mixbus )

Hope this helps!

-Ben

These best practices are very helpful to me, so I appreciate it. I can assume that the latency from the plugins was causing my problems. Thanks!