Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mark McFarlane]

Interesting. Curious where the added latency would come from though- inputs hit the A/D at roughly the same time, and once they are in the digital domain where does the latency come from? How does this factor in on a console with a near-zero total latency spec. of 0.8ms?

Channels and busses typically have their own EQ, gates, comps,... each of these algorithms consumes additional clock cycles to process the data stream,  this processing time is beyond the latency of the AD and DA conversion.  Internal FX units (verb, delays, multi-band comps, ...) take even more clock cycles to process.

One can design a console to have uniform delay through any and all paths, but then this built-in 'delay compensation' has to be set to the maximum processing time for the worst case scenario, which increases the overall latency of the console.

How this is addressed is a design choice.  I suspect most consoles will always include the delay of the channel strips whether they are engaged or not. Others may also include the bus 'channel strips' processing time, so that whether you go through a bus or not you get the same delay,....

As an example, using an internal effect unit for parallel compression (on drums, guitars, i.e two busses, one with an internal FX unit comp inserted and one bus straight thorugh) is a likely scenario for comb filtering.  A better choice might be to use a single bus and a compressor that has a built in mix ratio, so the compressed and uncompressed signal get the same delay.

The takeaway from this: You need to understand, for any particular console you are going to use, how routing and adding effects will change the latency of the data stream.  Each console is potentially different so a routing scheme that is safe (= 'comb filter free') in one console might not be safe in another console.  Sucks, but thats life in the digital world.

[Mac Kerr]

Interesting. Curious where the added latency would come from though- inputs hit the A/D at roughly the same time, and once they are in the digital domain where does the latency come from? How does this factor in on a console with a near-zero total latency spec. of 0.8ms?

This has been discussed at length over the past few years. the different latency comes from the different digital path length and different processing on each path.

A latency of 0.8ms may be near zero, but it is also non zero. Have you measured the latency on a console and found it to be 0.8ms? Most of the consoles I am familiar with are in the 2ms-2.5ms range, analog in to analog out.

Mac

[Samuel Rees]

What is a quick and dirty way to test latency? Send a signal generator out of a pro tools rig, then back in, measure the latency, then send it out through  the mixer and back in, then subtract?

[Mark McFarlane]

What is a quick and dirty way to test latency? Send a signal generator out of a pro tools rig, then back in, measure the latency, then send it out through  the mixer and back in, then subtract?

That'll work, but don't use the signal generator, use a hand drawn single sample spike.  Expect it to come back 'smeared' due to the DAD conversion but pick the first break.  This is actually good to know for your ProTools setup by itself. Some DAWS do an automatic round trip latency compensation (i.e. when you are overdubbing this is desirable.)  However, they base the compensation on what the audio driver reports which I have found to be inaccurate on many cases.  Cubase has a place to enter the 'extra latency'.

Measure your console channel strip direct to LR, Auxes, channel thru a buss, with effects applied as inserts in various places (Ideally insert and then disable he effect, its hard to pick the first break on some effects like verb)....

[Nikhil Mulay]

I think Midas (always-on) and Avid (selectable) are the only ones that offer automatic delay compensation.

   AFAIK Digico also have it. They have a different way if implementing it though. All the processing in all channels/groups is always on and the signal has the same latency regardless of whether the processing is on or not.

[Mac Kerr]

   AFAIK Digico also have it. They have a different way if implementing it though. All the processing in all channels/groups is always on and the signal has the same latency regardless of whether the processing is on or not.

I don't know what or how Digico has as far as delay compensation, but having all processing in all the time is not uncommon, and does not compensate for different path length.

Mac

[Nikhil Mulay]

  Whoops! Forgot to mention that the console compensates for different path lengths too! I found this out while talking to one of the digico reps that had come here for a training seminar.
   I was specifically interested in this as i wanted to use parallel compression on vocals.

[Patrick Tracy]

What is a quick and dirty way to test latency? Send a signal generator out of a pro tools rig, then back in, measure the latency, then send it out through  the mixer and back in, then subtract?

Or split the signal and loop one copy directly back into PT while the other one goes through the console. If you have enough inputs to PT you can capture various console paths/outputs at once.

[Samuel Rees]

Or split the signal and loop one copy directly back into PT while the other one goes through the console. If you have enough inputs to PT you can capture various console paths/outputs at once.

I'll try that, doesn't sound too hard.

Easy enough to find out about Digico - I'll try on an SD9 this weekend.

[ProSoundWeb Community]