Solved Automatic Plug-in Delay Compensation

[SwitchBack]

... and can it distinguish between (unwanted) latency and intentional delay?

S1/SP routinely applies plug-in delay compensation as an 'always on, non-configurable' feature. But how does it work? Does it ping a plug-in once and then keeps compensating for that delay for all instances of the plug-in in use? Or is it a dynamic process which also accounts for variable plug-in settings on each individual plug-in? And is it possible for plugins (e.g. a clean technical delay like this one) to flag that delay is intentional and should not be compensated? Would be good to understand this feature better, for more predictable results. Anyone?

 

[sintil8]

... and can it distinguish between (unwanted) latency and intentional delay?

S1/SP routinely applies plug-in delay compensation as an 'always on, non-configurable' feature. But how does it work? Does it ping a plug-in once and then keeps compensating for that delay for all instances of the plug-in in use? Or is it a dynamic process which also accounts for variable plug-in settings on each individual plug-in? And is it possible for plugins (e.g. a clean technical delay like this one) to flag that delay is intentional and should not be compensated? Would be good to understand this feature better, for more predictable results. Anyone?

Now retired and as a casual, but long time user of various DAWS honestly I do not know. This is a complex subject with many facets and dimensions.
This is worth discussing and am surprised at how little I understand... Is it based upon processor cycles or sound/samples in/out ?
I suppose there are many different answers?
The following Waves video explains it to some extent and I hope will open up the discussion. Is this how it works, as I do not know?

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

Kindest of regards

 

[SwitchBack]

Nice video. I get the purpose and the effects of delay compensation. But what if we want to add delay on purpose in S1/SP. How do we prevent other channels/buses being delayed automatically to compensate for the one with our intentional delay being 'late'?

 

[BobF]

Didn't watch the video ... my understanding is that plug-in delay compensation is based on reported I/O buffer sizes x sample rate. Intentional delay between input and output buffers don't get caught up in the calcs.

Processor speed/cycles depend on buffer sizes and sample rate as well, but impact overall performance rather than delay compensation. Example: smaller buffer(s) and higher sample rates require the processor(s) to work harder to keep things moving along.

 

[SwitchBack]

That can't be the full story. Between the buffers is where the plug-in's calculations happen: Complex plugins need more throughput clock cycles than more simple plugins. And I know that there's a lot of clock cycles in the time of 1 sample but in that time there's also a lot more to do than dealing with just one plugin's calculations. Maybe plugins have to report clock cycles in-to-out as part of the VST (...) standard? Something like that. So I'm interested in how the mechanism works, and maybe knowing results in using better.

 

[sintil8]

That can't be the full story. Between the buffers is where the plug-in's calculations happen: Complex plugins need more throughput clock cycles than more simple plugins. And I know that there's a lot of clock cycles in the time of 1 sample but in that time there's also a lot more to do than dealing with just one plugin's calculations. Maybe plugins have to report clock cycles in-to-out as part of the VST (...) standard? Something like that. So I'm interested in how the mechanism works, and maybe knowing results in using better.

Yes, that's something I was drifting toward, but @BobF mentioned something "based on reported I/O buffer sizes x sample rate", I have heard that quoted a few times in other places and thought it meant that each VST reported a figure, an actual compensation No.#. Never ever having developed a VST myself I struggle to understand how that could be done ?
As to how a Daw keeps all the plates spinning at the same rate is some kind of binary Voodoo

In the video I posted there was an option to switch off Delay Compensation on plugins, which as far as I know you cannot do in SO/SP. I can see it could be helpful in certain situations and perhaps is something SP going forward might consider and be a way to answer your initial question.

Kindest of regards

 

[BobF]

That can't be the full story. Between the buffers is where the plug-in's calculations happen: Complex plugins need more throughput clock cycles than more simple plugins. And I know that there's a lot of clock cycles in the time of 1 sample but in that time there's also a lot more to do than dealing with just one plugin's calculations. Maybe plugins have to report clock cycles in-to-out as part of the VST (...) standard? Something like that. So I'm interested in how the mechanism works, and maybe knowing results in using better.

Maybe @Lukas knows the inner workings

 

[AndreasB]

Nice video. I get the purpose and the effects of delay compensation. But what if we want to add delay on purpose in S1/SP. How do we prevent other channels/buses being delayed automatically to compensate for the one with our intentional delay being 'late'?

Well,- for my knowledge,
it's sufficient to know, that the plug-ins are "responsible" to report the needed latency to the DAW for the (overall) automatic latency compensation.
Thus, it is possible for a plugin itself to "fake" the real latency, as long as it knows the sample rate.
So it can report to the DAW a latency of e.g. 1.000 samples latency, but in reality only needing 600.
The result would be some "overcompensation" and the resulting signal would be 400 samples "earlier" than the rest.
Same works in opposite direction for a delay, where the REAL latency is 1.400 samples. The result would be a 100% wet delay of 400 samples.
This is what some KI told me:

 

[SwitchBack]

OK, that's clear then: The plug-in reports and then the DAW executes. Thanks!