PARIS and Native Plug-in Latency


"Latency" is the time delay a plugin or other process introduces into an audio stream. Some plugins process in "real time"; others introduce delays into the audio stream that can range from a single sample up to well over a full second. This can create obvious problems, from disrupting internal phase relationships between multi-mic audio (or between "wet" and "dry" signals) all the way to "dragging" the timing of a track.

Important note: in the PARIS manual, EDS plugins are referred to as "native" plugins (as distinct from VST/DX plugins) - evidently because at that time EDS plugins were thought of as being "native" to the PARIS hardware. However, since the days of PARIS, the audio industry has standardized the term "native" to mean "plugins that run on your CPU". Terminology here reflects that current usage, rather than the manual's minority usage. Hence all plugins that are accessed through the EDS plugin slots in your Mixer Window and run on the ESP2 chips of the EDS cards (eg stock, Skunkworks or Mike Audet) will be referred to here as "EDS Plugins". All plugins that are accessed via the VST/DX slots in your Mixer Window - whether run on your computer's CPU (eg the VST/DX plugins referred to here) or on other resources such as UAD cards - will be referred to as "Native Plugins" for simplicity. There's little to know about the latency of PARIS' EDS plugins - they are all either "zero latency", a single sample, or user-determined (i.e. "lookahead"); click here for more details.

The PARIS app, last updated in 2001, lacks internal latency compensation (sometimes called "ADC" or "PDC") for either native or EDS plugins, so PARIS users have evolved a variety of workarounds.

Sidebar - Latency in perspective: How much is 64 samples of latency (RenComp etc) in musical terms?
Consider a song with a tempo of 129 BPM and a sample rate of 44.1k. Insert a RenComp on a track with 64 samples of latency. How much is that in real terms? At 129 BPM it translates to a delay of one-tenth of one 32nd note. At Logic's internal MIDI resolution of 960 "ticks" per quarter note, a single instance of RenComp in a 129 BPM song would be equivalent to three "ticks" of delay. By way of comparison, the default setting of the "Humanize" function in Logic which slightly randomizes MIDI times is a random value with a range +/- 10 ticks.
What this means is that the amount of latency is so negligible as to be inaudible unless you're combining multiple mics from a single source, which has the potential to disrupt phase relationships between the mics (one simple workaround would be to make sure to insert the same plugin - say a Ren Comp - on all mics from the same source, and simply set the threshold too high to trigger on the ones you don't want effected).
How much of an issue is this? It depends; many latency issues are far below the threshold of direct perception (delays ranging from single samples up to a couple of milliseconds are below the threshold at which even trained listeners can perceive them as discrete events). They can only be perceived indirectly through their effects on frequencies in combined audio (eg "comb filtering", often heard as a "phasey" quality or a "hollowing" of the blended sound). Where the latency is below the direct detection threshold, and there's no need to combine multi-mic'd (or "wet" and "dry") signals, the small amounts of latency caused by plugins marked in green below are essentially irrelevant and can safely be ignored by most users (although be aware that latencies are cumulative if chained in series).

In other situations a single sample of latency may be sufficient to cause issues. When splitting multi-mic'd recordings, blending "wet" and "dry" signals, or where latencies are greater than the direct detection threshold (ie UAD plugins), users can -

1) avoid the issue (eg by keeping things that require exact sample alignment like multi-mic'd drums on the same submix and avoiding plugins that introduce latency).
2) attempt to manually compensate for latency by nudging or sliding audio on the edit screen, or using plugins such as SampleSlide
3) automatically compensate for latency via systems such as Vertex DSP's FaderWorks.

Those who want to avoid the issue altogether can simply avoid plugins marked in red or green below. Those seeking to manually compensate for latency can look up the exact latency of a particular plugin and nudge their audio earlier by that amount - or nudge (or SampleSlide) all other audio later by that amount (see important notes in sidebar to right for things that affect this approach).

Thanks to the efforts of PARIS guru Dimitrios, those users who want their latency automatically compensated gained a new more convenient option for relative latency compensation for native plugins in 2009. Vertex DSP's FaderWorks uses a clever approach; a FaderWorks plugin is inserted on each channel of the PARIS mixer; FaderWorks keeps track of the latencies of each new plugin and delays all other channels in the submix accordingly if necessary.

FaderWorks is not full global latency compensation - that particular submix will be delayed in relation to the edit screen (and other non-FaderWorks submixes). This is because latency always represents a "delaying" of audio, so the only true correction for that would be to "advance" that audio the same amount, playing it back "early"; FaderWorks can only affect audio that has already passed through the native inserts, ie it can't play audio any earlier than it receives it. But it's a great solution to correct *relative* latencies between channels within submixes. Plugin delays are still cumulative per channel - however, Faderworks keeps track of what each channel "needs" for compensation, and the maximum overall delay FaderWorks will introduce in a submix will be no more than that of the most "latent" channel. Unless you're using highly "latent" plugins (or many native plugins with smaller latencies in series on a single channel), you may not notice any perceptible delay.

Note that when you are "nudging" on the editor screen in PARIS, the "nudge" values are not precise. PARIS power-user DJ explains in depth: "The nudge values are not consistent with what one would expect the samples to be per ms, and they are also not consistent with themselves. Meaning that a 1ms nudge would be expected to be 44 samples [assuming a sample rate of 44.1k] but is actually 80. A 10ms nudge isn't 10 X 80 or 800 samples though, it's actually 480."

PARIS Editor: Displayed vs. Actual Values
Displayed ValueActual movement in editor
"1ms"80 samples
"5ms"240 samples
"10ms"480 samples
"25ms"1120 samples
"50ms"2240 samples
"75ms"3360 samples
"100ms"4480 samples

DJ: "Using sampleslide to assist the nudge function... for UAD-1 plugins, Sampleslide presets were as follows:"

Compensating for UAD plugin latency with "Sampleslide" plus "nudge"
#TypeSampleslide valueAdd this much "nudge" in Editor
1Plugin1536slide 4 x 100ms in Editor
1Pultec1523slide 4 x 100ms in Editor
2Plugins3072slide 8 x 100ms in Editor
2Pultecs3046slide 8 x 100ms in Editor
1Plugin 1 Pultec3059slide 8 x 100ms in Editor
2Plugins 1 Pultec4595slide 12 x 100ms in Editor
2Pultecs 1 Plugin4582slide 12 x 100ms in Editor
3Plugins4608slide 12 x 100ms in Editor)
3Pultecs4569slide 12 x 100ms in Editor)

Native Plugin Latencies
ManufacturerPlug-in NameLatency in samples
xxxSimple Limiter0
xxxSoft Overdrive0
xxxGene comp mono0
xxxClassic_compressor0
CamelCamelphat_free0
ChunkwareVanilla44
MnCompV1.r0
DLimiter0
Dbcompressor0
DSPFXStudioverb0
DSPFXAcousticverb0
DSPFXChorus0
DSPFXautopan0
DSPFXAural Exciter0
DSPFXDelay0
DSPFXOptimizer33
DSPFXFlanger1024
E_phonicXpressor0
IzotopeAlloy1
IzotopeOzone??1111??
KjaerhusGCO-10
LuxonixLFX13100
MDAdynamics0
MDAloudness0
MJcompressor0
MJmultiband0
TLSaturated Driver0
WavesAPI 550A0
WavesAPI 550B0
WavesAPI 5600
WavesAPI 25000
WavesAudioTrack0
WavesC1 Compressor0
WavesC1 Gate0
WavesC1 Comp-Gate340
WavesC1 Comp-sc340
WavesC4 Multiband64
WavesDeBreath32,384
WavesDeEsser0
WavesDoppler0
WavesDoubler0
WavesEnigma0
WavesGTR3 Amps34
WavesGTR3 Stomps0
WavesGTR2 Amps34
WavesGTR2 Stomps0
WavesIR-1 Convolution Reverb0
WavesIR-L Convolution Reverb0
WavesIR-360 Convolution Reverb0
WavesL1 Ultramaximizer64
WavesL2 Ultramaximizer64
WavesL3 Multimaximizer3528
WavesL3 Ultramaximizer3528
WavesL3-16 Multimaximizer6207
WavesL3-LL Multimaximizer64
WavesL3-LL Ultramaximizer64
WavesLinear Phase Equalizer Broadband2679
WavesLinear Phase Equalizer Lowband2047
WavesLinear Phase Multiband3528
WavesMaxxBass0
WavesMaxxVolume64
WavesMetaFlanger0
WavesMondoMod0
WavesMorphoder639
WavesPAZ Analyzer0
WavesPS22 Split / X-SplitN/A
WavesPS22 SpreadN/A
WavesQ100
WavesQ-Clone344
WavesRenaissance Axx64
WavesRenaissance Bass0
WavesRenaissance Channel65
WavesRenaissance Compressor64
WavesRenaissance DeEsser64
WavesRenaissance Equalizer0
WavesRenaissance Reverb0
WavesRenaissance Vox64
WavesS1 Stereo Imager0
WavesSoundShifter6946
WavesSSL E Channel0
WavesSSL G Equalizer0
WavesSSL G Master Buss Compressor1
WavesSuperTap0
WavesTransX Multi64
WavesTransX Wide64
WavesTrueVerb0
WavesUltraPitch8239
WavesV-Comp0
WavesV-EQ30
WavesV-EQ40
WavesWaves Tune3072
WavesWaves Tune LT3072
WavesX-Click2625
WavesX-Crackle2625
WavesX-Hum0
WavesX-Noise5120
WavesZ-Noise34,702
WavesC360 Surround Compressor64
WavesIDR360 Surround Bit Re-Quantizer0
WavesL360 Surround Limiter64
WavesLFE360 Low Pass Filter0
WavesM360 Surround Manager0
WavesM360 Surround Mixdown0
WavesS360 Surround Imager0
WavesS360 Surround Panner0
WavesR360 Surround Reverb0

There are no comments on this page. [Add comment]

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki