View Single Post
  #7  
Old 10-21-2006, 11:36 PM
JFreak's Avatar
JFreak JFreak is offline
Moderator
 
Join Date: Jan 2003
Location: Tampere, Finland
Posts: 16,337
Default Re: LATENCY and DELAY COMPENSATION

Quote:
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
__________________
Janne
What we do in life, echoes in eternity.
Reply With Quote