The PARIS Wiki : NativeLatencyDatabase

• Categories
• PageIndex
• RecentChanges
• RecentlyCommented
• Login/Register
• Search:

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"); ParisLatency 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.

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.

Native Plugin Latencies

Manufacturer	Plug-in Name	Latency in samples
xxx	Simple Limiter	0
xxx	Soft Overdrive	0
xxx	Gene comp mono	0
xxx	Classic_compressor	0
Camel	Camelphat_free	0
Chunkware	Vanilla	44
Mn	CompV1.r	0
D	Limiter	0
Db	compressor	0
DSPFX	Studioverb	0
DSPFX	Acousticverb	0
DSPFX	Chorus	0
DSPFX	autopan	0
DSPFX	Aural Exciter	0
DSPFX	Delay	0
DSPFX	Optimizer	33
DSPFX	Flanger	1024
E_phonic	Xpressor	0
Izotope	Alloy	1
Izotope	Ozone	??1111??
Kjaerhus	GCO-1	0
Luxonix	LFX1310	0
MDA	dynamics	0
MDA	loudness	0
MJ	compressor	0
MJ	multiband	0
TL	Saturated Driver	0
Waves	API 550A	0
Waves	API 550B	0
Waves	API 560	0
Waves	API 2500	0
Waves	AudioTrack	0
Waves	C1 Compressor	0
Waves	C1 Gate	0
Waves	C1 Comp-Gate	340
Waves	C1 Comp-sc	340
Waves	C4 Multiband	64
Waves	DeBreath	32,384
Waves	DeEsser	0
Waves	Doppler	0
Waves	Doubler	0
Waves	Enigma	0
Waves	GTR3 Amps	34
Waves	GTR3 Stomps	0
Waves	GTR2 Amps	34
Waves	GTR2 Stomps	0
Waves	IR-1 Convolution Reverb	0
Waves	IR-L Convolution Reverb	0
Waves	IR-360 Convolution Reverb	0
Waves	L1 Ultramaximizer	64
Waves	L2 Ultramaximizer	64
Waves	L3 Multimaximizer	3528
Waves	L3 Ultramaximizer	3528
Waves	L3-16 Multimaximizer	6207
Waves	L3-LL Multimaximizer	64
Waves	L3-LL Ultramaximizer	64
Waves	Linear Phase Equalizer Broadband	2679
Waves	Linear Phase Equalizer Lowband	2047
Waves	Linear Phase Multiband	3528
Waves	MaxxBass	0
Waves	MaxxVolume	64
Waves	MetaFlanger	0
Waves	MondoMod	0
Waves	Morphoder	639
Waves	PAZ Analyzer	0
Waves	PS22 Split / X-Split	N/A
Waves	PS22 Spread	N/A
Waves	Q10	0
Waves	Q-Clone	344
Waves	Renaissance Axx	64
Waves	Renaissance Bass	0
Waves	Renaissance Channel	65
Waves	Renaissance Compressor	64
Waves	Renaissance DeEsser	64
Waves	Renaissance Equalizer	0
Waves	Renaissance Reverb	0
Waves	Renaissance Vox	64
Waves	S1 Stereo Imager	0
Waves	SoundShifter	6946
Waves	SSL E Channel	0
Waves	SSL G Equalizer	0
Waves	SSL G Master Buss Compressor	1
Waves	SuperTap	0
Waves	TransX Multi	64
Waves	TransX Wide	64
Waves	TrueVerb	0
Waves	UltraPitch	8239
Waves	V-Comp	0
Waves	V-EQ3	0
Waves	V-EQ4	0
Waves	Waves Tune	3072
Waves	Waves Tune LT	3072
Waves	X-Click	2625
Waves	X-Crackle	2625
Waves	X-Hum	0
Waves	X-Noise	5120
Waves	Z-Noise	34,702
Waves	C360 Surround Compressor	64
Waves	IDR360 Surround Bit Re-Quantizer	0
Waves	L360 Surround Limiter	64
Waves	LFE360 Low Pass Filter	0
Waves	M360 Surround Manager	0
Waves	M360 Surround Mixdown	0
Waves	S360 Surround Imager	0
Waves	S360 Surround Panner	0
Waves	R360 Surround Reverb	0

• [Source]
• [History]
• 2015-10-12 13:26:49
• Owner: admin
• Your hostname is ec2-3-147-27-129.us-east-2.compute.amazonaws.com

Valid XHTML :: Valid CSS: :: Powered by WikkaWiki