Question about latency compensation

Hi,

here’s my problem. I usually record bass tracks straight from a nice DI box that I have, then send the recorded signal to a miked bass amp and blend the two sources (direct and miked) to achieve the best results (in my opinion at least). My problem is, the signal I get from the mic is slightly delayed from the direct one, as it is supposed to be because of cable lengths, round trip latency ect.

This delay is very little, and noticeable only because the blended signal loses a bit of attack (or comparing the regions at max zoom). I send the direct signal to the amp using a pre-fader send in ardour. My question is: is there a way to compensate this latency other than doing it by manually moving the recorded region backwards?

Thanks

Alessio

I don’t think bus latency is usually going to be a big deal - but it depends what you’re doing. If you have a shared reverb on a bus fed by all the tracks, a tiny delay won’t matter. With the bass tracks blended into a bus, above, it will just sound like the bass player moved six inches further away from the band (or something similarly inconsequential). However, there might be phase issues if some kind of routing arrangement tries to blend two versions of the same signal at the master bus, one version arriving direct and one via a bus.

I think you are just experimenting finite sound speed. It’s the delay from the speaker to your mike.
When you double record the same source directly and from an aplifier, you always have to compensate
the delay and avoid combfiltering.

mcgruff: Ardour 3.0 will not include bus latency compensation, but hopefully a post-3.0 version will (maybe 3.1??). It would be great if could support http://tracker.ardour.org/view.php?id=3290

I’m very interested if your solution works for vervelover!

@vervelover: With your approach (first recording DI then reamping) you most likely suffer from what Benjamin described in point 2.

IMHO the first thing to do would be to connect your interface’s analog output to it’s analog input directly and measure what additional latency it causes. Assuming that you use qjackctl enter this value (in samples/frames) in the field “Input Latency” in the setup dialog. This should compensate for the additional latency caused by the conversion.

Depending on how far you place the microphone from the amp there still might be a delay. For this I would either use a short delay on the DI track, align the regions manually or give LinuxDSP’s plugin a try.

Thanks everybody for the prompt answers! I also think benjamin’s point 2 is the issue here. I always use Linuxdsp Gate plugin to correct phase problems, but here I can clearly see the miked track region being slightly delayed compared to the direct track region if I zoom in both… I’ll try mcgruff solution to measure the correct latency and report…

@vervelover: You can adjust the position of recorded audio on the timeline, but, as Benjamin says, my gate plugin (which I believe you already have :slight_smile: ) has a phase rotator built in (seperate from the gate). This is designed to offer a more ‘analogue’ way of compensating for phasing differences in multi-microphone and / or DI’d and mic’d setups. Its a bit like the ‘IBP’ or In Between Phase:

http://www.littlelabs.com/ibp.html

It might be worth experimenting with the control in my plugin - the idea behind emulating a more analogue kind of adjustment, rather than just adding a delay, was to enable more subtle ‘sub-sample’ adjustments to fix the phasing issues, while keeping the sense of ‘space’ that the actual delay inherent in some mic’d acoustic setups imparts. It may work for you, or it may be that actual delay compensation is better in this case, no harm in trying it though.

Connect the DI input to two separate tracks. On one of these tracks, add an Ardour insert for the amp send/return. The insert has a button to click to measure latency of the send/return loop. After that, Ardour will automatically compensate.

Don’t forget to arm both tracks when you’re recording.

For mixing, you can do one of two things.

(1) Create a “bass” group in the mixer and add the tracks to it. This locks the faders together so you can adjust bass level without altering the balance between DI and amp. Toggle the group “active” status to turn the lock on and off (it will need to be off to adjust the blend).

(2) Disconnect the two bass tracks from the master outs and route them through a single bus. Now you’ve got a single bus fader for bass volume, and the track faders to adjust the blend.

AFAIK buses introduce some extra, uncompensated latency. The DI/amp signals will stay in phase, but there will be a tiny delay relative to the other signals being fed into the master bus. I think Ardour 3 will fix that - someone else had better confirm I’ve got that all right though.

Hi vervelover,

if you have set everything up correctly, Ardour2 should compensate any latencies everything for you (Ardour3 is another case right now, I know a latency bug there).

There are two possibilities I can think of that woul explain your problems:

  1. You are using busses which are not latency compensated in A2.

  2. You are hearing the latency of your sound card’s D/A A/D conversion. This latency is very tiny, but can be audible because the two signals, of which one went one time more through the converter, won’t be 100% in phase. It also cannot be detected or known by Ardour. If that is your problem, you might be able to fix your problem with a phase shifter like LinuxDSP’s gate plugin, but I am not sure of that.

Best,
Benjamin

@mcgruff: For me and others who tend to utilize outboard gear, this really is a major issue. For example an outboard compressor for a drum bus can easily introduce several milliseconds latency or more, depending on your soundcard. Sometimes I’ve bounced the processed busses back into individual tracks and tweaked the phase to match the originals, but that’s not what I would really want to concentrate on when doing serious mixing. I really love Ardour though and I’m really looking forward on a fix for this in 3.x versions.