pro tools plugin latency weird problem

joeymusicguy

Member
Sep 21, 2006
3,743
5
38
indiana
www.myspace.com
so i just spent an ass load of cash on plugins for my pt rig

only to load up a tdm version of waves c1 at 44.1 kHz session and find 3 samples of latency when the rtas version is 0

wtf?
 
Does the C1 have 3 samples of latency, or is it being compensated by 3 samples? Generally RTAS plugs have more latency than their TDM equivalents (at least that's generally the case in my experience).
 
Does the C1 have 3 samples of latency, or is it being compensated by 3 samples? Generally RTAS plugs have more latency than their TDM equivalents (at least that's generally the case in my experience).

True, the 3 samples you are seeing Joey might refer to the amount that the TDM track is being delayed to compensate for latency incurred by other plugins somewhere else? I don't have much experience with HD and the delay compensation it uses :/
 
let me re-explain this in more detail

empty project, session is 44.1 kHz

one mono track, one insert, mono waves c1

rtas version is 0 samples of latency, tdm version (more expensive, less latency version) is THREE samples of latency

i spent twice the cost for TDM plugins (native is half the price of tdm) and the TDM version is slower than the rtas version

i havent tested others yet but wtf, this isnt right? someone please explain this... (should probably post on the duc but those guys take like 5 days to reply)
 
It isn't right dude, but that's TDM for you. I seriously cannot think of any reason to entertain that platform. Just stick with RTAS and use the juice of what I'm assuming is your immense 8 core Mac Pro. Running plug-ins off those DSP cards for simple music production these days is just lunacy IMO.
 
that'd probably be the Tdm signal path.... or do you have it on an aux? either way, it'll be compensated for if you turn on the delay compensation engine
 
pro tools is mad weird when it comes to plugins and software instruments

but i'll play the game if i get to run everything in real time and not have to bounce

which was my original goal...
 
I looked into this (it was really bugging me) and may have found an explanation - take this with a grain of salt because I'm not 100% sure (and I'd like to check this on my own HD rig). It seems to make sense though.

The TDM version of C1 is most likely incurring three samples of latency because of the inherent latency of the TDM bus (which, according to McDSP, is 3 samples). The plug-in itself most likely has zero samples (or minimal) internal latency.

The RTAS version, since it's first on the track, is not reflecting any latency from the TDM bus, as its processing requirements are being handled by the CPU. However, any native plug-in still has to deal with latency created by whatever playback buffer is selected, which would give the RTAS version of C1 a maximum latency of whatever the playback buffer is set to (which is likely much more than 3 samples).

Make sense? I think so but I'd like to look into it more. If anyone else has any insight it'd be more than welcome.
 
I looked into this (it was really bugging me) and may have found an explanation - take this with a grain of salt because I'm not 100% sure (and I'd like to check this on my own HD rig). It seems to make sense though.

The TDM version of C1 is most likely incurring three samples of latency because of the inherent latency of the TDM bus (which, according to McDSP, is 3 samples). The plug-in itself most likely has zero samples (or minimal) internal latency.

The RTAS version, since it's first on the track, is not reflecting any latency from the TDM bus, as its processing requirements are being handled by the CPU. However, any native plug-in still has to deal with latency created by whatever playback buffer is selected, which would give the RTAS version of C1 a maximum latency of whatever the playback buffer is set to (which is likely much more than 3 samples).

Make sense? I think so but I'd like to look into it more. If anyone else has any insight it'd be more than welcome.

Does TDM bypass the playback buffer somehow then?
 
I looked into this (it was really bugging me) and may have found an explanation - take this with a grain of salt because I'm not 100% sure (and I'd like to check this on my own HD rig). It seems to make sense though.

The TDM version of C1 is most likely incurring three samples of latency because of the inherent latency of the TDM bus (which, according to McDSP, is 3 samples). The plug-in itself most likely has zero samples (or minimal) internal latency.

The RTAS version, since it's first on the track, is not reflecting any latency from the TDM bus, as its processing requirements are being handled by the CPU. However, any native plug-in still has to deal with latency created by whatever playback buffer is selected, which would give the RTAS version of C1 a maximum latency of whatever the playback buffer is set to (which is likely much more than 3 samples).

Make sense? I think so but I'd like to look into it more. If anyone else has any insight it'd be more than welcome.
yep..
thats what i meant
 
Does TDM bypass the playback buffer somehow then?

TDM plugs don't have to leave the TDM environment (to be sent to the native CPU) so I don't think they're affected by CPU-induced latency. I could be wrong though.

Here's a great bit of info from the Digi forums:

Pro Tools HD is a digital mixing an dprocessing environment that exists on DSP chips on cards (HD, HD Accel) installed in PCI(and X or e) slots in a host computer system. I refer to this as the "TDM Environment." The TDM Mixer would be a misnomer, and would be confusing due to the TDM Mixer being an actual plug-in.

The TDM Environment is that digital mixing and processing environment as it exists on those cards, but it also includes the I/O devices attached directly to it (typically a Digi 192 or 96 I/O). Transmission of signal within this entire TDM Environment usually takes nanoseconds; this includes to and from the ADC and DAC in those I/O devices. The A2D and D2A conversion takes time, but I will not touch upon this directly in this post.

So- you have your TDM Environment. So long as nothing has to leave the Environment, processing times are entirely and only dependent upon travel time (nanoseconds, maybe equalling a sample in time for most; compound travel routes will accumulate, of course), and "time to process." Many processes only require a sample or so of time, while others may require more time due to complexity or utilization of processes, such as a "look-ahead." Since the I/O devices are connected directly to the TDM Environment, so long as the signal does not need to leave the Environment (except via the I/O), no additional "doorways" or "gates" are needed, or used.

Since the purpose of Pro Tools is to record and playback audio, one also requires a storage medium. Hard drives! Since the TDM ENvironment lives in a host computer, one can use the hard drives hooked to it. But, the TDM Envirnment needs a doorway, or gate, to allow signal to enter the TDM Environment when laying back audio, and it also needs one to leave the Environment when recording ot the hard drive. This doorway, or gate, is a "Voice." It is a one way, single lane gate or doorway. So, a stereo track playing back audio will require two of those voices to get that audio data into the TDM Environment. For a 5.1 audio file to stream in...you guesed it- 6 voices. Now, Audio tracks are the only type that allows audio to stream to and from the hard drives. As such, even if no recording or playback is being done, an Audio track will automatically use a voice per lane of track width. The Audio track can only either playback or record at one time, so that voice, being versatile, can allow the audio to flow either way...but still, only ONE way at a time.

Aux In tracks are different. They do not have any ability to send or receive audio from the hard drive. Input and Output of the Aux In can only be to busses (internal, input, or output type busses). But, they CAN use RTAS plug-ins. And RTAS plug-ins require the use of the host CPU(s) for processing. To do so, the signal must leave the TDM Environment to do so. Yep- to leave, a voice. To get back in, a voice. PER track width. So, a stereo RTAS plug-in on a stereo Aux In requires 2 voices to send the audio out to host, and then 2 more to get back in. If you have a mono Aux In with a plug-in that produces a wider return stream- say, mono->stereo, then only one voice is needed to LEAVE the Environment, but two will be required for the two streams to get back in.

TDM plug-ins use the DSP chips in the TDM Environment, and thus no voices are required to do so with a signal already in the Environment. But, if you have an RTAS plug-in before the TDM plug-in, the signal will require the voices to leave and re-enter. If you use an RTAS as the first plug-in on an Audio track that is playing back audio from the hard drive, then there is no reason to enter the TDM Environment and then exit again to do the RTAS processing. That would be stupid. So, the data leaves the drive, processes RTAS, and THEN enters the TDM Environment. Put a TDM Plug-in first, and then an RTAS, and you have to enter to process the TDM plug-in, exit for RTAS< and then re-enter to finish the journey thru the mixer and finally out via an Output Buss to the I/O device, converted, and out to your monitors.

Using all of that info, it can become aparent how one can get into BIG trouble if they do not plan out things well. As an example... Say you have a 5.1 audio file streaming in to an Audio track, you buss that to an Aux In, and place the following on there, in this order: 5.1 RTAS, 5.1 TDM, 5.1 RTAS, 5.1 TDM, 5.1 RTAS. Add it up: 6 voices for the Audio track, and since it is utilizing an Internal Buss in the TDM Environment, it MUST enter via the Audio track and go thru the ENvironment before being passed to that first RTAS plugin. 6 voices to leave the Environment for RTAS #1, 6 voices back in for the next plugin, TDM #1, 6 voices out for RTAS #2, 6 voices back in for TDM #2, 6 voices out for RTAS #3, and finally, 6 more voices to get back into the TDM Environment for final bussing to the Output Buss and on to the I/O device. Grand total? 42 voices!!!

Voicing Laws can be confusing at first, but once you understand it, it is relatively easy to figure things out, and plan accordingly. This, plus Automatic Delay Compensation DSP requirements, require consideration when purchasing an HD system. As you can see, by opting for less HD power, RTAS will come into play, and thus voices. Voices require a more complex TDM Mixer to be built in the TDM ENvironment, and Auto Delay Comp (long, especially) eats more. That single HD Core's DSP can disappear quite quickly, and thus understanding your tools becomes very vital. While the home composer can get away with an HD 1 (Accel, even better), a project studio that might work at 24/96k, or want to use alot of RTAS plug-ins, might end up needing to do some pre-planning to get that HD1 to work for them, and an HD2 might be abetter solution. Start doing 24/96k with 5.1 session and ADC Long enabled...yeah, you guessed it: HD3 Accel time, hands down.

LE does not "suffer" from voicing concerns. however, since it is a completely different Environment, it has pros and cons of it's own, in comparison.