LATENCY and DELAY COMPENSATION

[detroitkruk]

searches are absolutely worthless on both of these subjects...please help:

ARE YOU GUYS TRACKING AND MONITORING IN THE BOX WITH LE? LIKE, REALLY, PRACTICALLY, MAKING MONEY AND TRACKING IN THE BOX, SOFTWARE MONITORING?

EXACTLY WHEN IS THE LE DELAY COMPENSATION AN ISSUE?

thank you in advance...putting my own studio together after years of working with TDM at work...just can't afford it...the stuff in this forum about the muscled-up computers is amazing...just want the straight facts...

detroitkruk

[JFreak]

EXACTLY WHEN IS THE LE DELAY COMPENSATION AN ISSUE?

Every time you plug in a 3rd party product. External effects, UAD and PowerCore to be more exact. When you don't use plugins, or use only latency-free RTAS plugs, delay compensation is a non-issue.

(Some RTAS plugs introduce several samples of internal processing delay. PTLE does not compensate such latencies at all. If you want to deal with those, you'll have to do it manually. Waves Renaissance plugs are notorious for this.)

But as a rule of thumb: RTAS does not need to be compensated (as it is already compensated within the hardware buffer setting) and you only get latency from external I/O.

[nikki-k]

Every time you plug in a 3rd party product. External effects, UAD and PowerCore to be more exact. When you don't use plugins, or use only latency-free RTAS plugs, delay compensation is a non-issue.

(Some RTAS plugs introduce several samples of internal processing delay. PTLE does not compensate such latencies at all. If you want to deal with those, you'll have to do it manually. Waves Renaissance plugs are notorious for this.)

But as a rule of thumb: RTAS does not need to be compensated (as it is already compensated within the hardware buffer setting) and you only get latency from external I/O.

Sorry, bzzt, wrong. Pro Tools LE does not compensate for RTAS plugins, period.
HW Buffer has nothing to do with the RTAS plugins and compensation either.
If a plugin uses a sample or more of process time, it wil not be compensated for.
If a plug-in doesn't need extra time to process, it doesn't add latency.

[gibson_sg]

Hi, I think this is what you're looking for:

http://akmedia.digidesign.com/suppor...E&MP_29303.pdf

I got that link from here: http://www.digidesign.com/index.cfm?...54&itemid=5143

Here is a quote from that technical document:

"Host-based Pro Tools systems such as Pro Tools LE and Pro Tools M-Powered, on the
other hand, do not have this Automatic Delay Compensation feature. However, in
most cases, latency with host-based systems is automatically compensated for due
to the way the host-based mixing/processing engine works. In cases where
additional delay compensation is necessary to ensure a mix stays time aligned
and/or phase accurate, there is a way to manually compensate for latency with hostbased
Pro Tools systems using the DigiRack Time Adjuster plug-in, or by slightly
moving or “nudging” tracks."

Hope that helps

[nikki-k]

Hi, I this this is what you're looking for:

http://akmedia.digidesign.com/suppor...E&MP_29303.pdf

I got that link from here: http://www.digidesign.com/index.cfm?...54&itemid=5143

Here is a quote from that technical document:

"Host-based Pro Tools systems such as Pro Tools LE and Pro Tools M-Powered, on the
other hand, do not have this Automatic Delay Compensation feature. However, in
most cases, latency with host-based systems is automatically compensated for due
to the way the host-based mixing/processing engine works. In cases where
additional delay compensation is necessary to ensure a mix stays time aligned
and/or phase accurate, there is a way to manually compensate for latency with hostbased
Pro Tools systems using the DigiRack Time Adjuster plug-in, or by slightly
moving or “nudging” tracks."

Hope that helps

Sorry, but as I said in another thread, that document is not 100% correct, and has errors. I have spoken with a rep at Digi who is in the dept dealing with that stuff. I am trying ot get an official email I can post, cut-n-paste, or something, as proof positive. I would much prefer if DIgi would remove that doc, correct it, and then repost it.

As it stands today, that document, with errors, cannot be a factual piece of data to reliably quote from IMO.

I was told, paraphrased, "if there is ANY latency in the plug-in, you're SOL basically..." I was then told most Digirack plug-ins do not incur latency/delay when processing; Maxim would be an example of one that does add delay...

[JFreak]

If a plug-in doesn't need extra time to process, it doesn't add latency.

EVERY plugin needs extra time. Analog gear doesn't. Even the best TDM plugs add few samples of connection latency, and surely RTAS plugs do too -- and this connection latency is compensated within the hardware buffer.

[JFreak]

I was told, paraphrased, "if there is ANY latency in the plug-in, you're SOL basically..." I was then told most Digirack plug-ins do not incur latency/delay when processing; Maxim would be an example of one that does add delay...

You're right, but you're talking about different kind of latency. First there is this connection latency which is compensated, but then there's this "internal latency" which isn't -- because I don't think plugins have a system to report this internal processing latency back to the mixer. So this kind of latency is not compensated, sadly.

You need to understand the concept of plugin connection latency. This is the amount of samples it takes for the plugin to begin processing output after it has got its input. There is always at least one sample of connection latency, as the plugin cannot guess what kind of input it will see in the future. It has to have time to do the math. TDM connection latencies are sometimes as low as 2 or 4 samples (Impact and ReVibe are such great plugs), and this kind of delay IS compensated within the playback buffer for the RTAS plugs. That is the whole reason for the buffer! The mixer delays the output to give CPU time to process, and the output is said to be phase coherent (which means that connection latency is compensated for).

Say you have a limiter that uses some look-ahead algorithm. It is clear that the plug needs to delay the signal to be able to look ahead, but as it will be processing audio during that time it is not "connection latency" but depends on the algorithm it uses to process the output. So the output is delayed beyond the connection latency, but only the connection latency is compensated for. Yes, it sucks, but what can you do? Stop using Maxim