Dynamic latency change: where we stand

[p0nce]

Would dynamic latency be possible, and what would it take?

TL;DR it's not always doable, nor desirable!

What are the pluses and minuses?

An ultimate goal would be to allows a signal sub-graph to have latency reported at any time, not necessarily at initialization or even before-hand (like it is today).

However every format is a bit different with regards to latency.

---

VST2

When receiving a "Resume" opcode, VST2 allows is to compute latency there and update it. Other developers report that all hosts follow this correctly. A parameter that changes latency has to be marked with nonAutomatable() in buildParams(). (EDIT: not all plugin do that) However, Voxengo says that users don't like a parameter that need transport restart. While transport is on, in VST2 no latency change will be applied and PDC will be wrong until the user restart it.

That's a key reason why many plug-ins currently pessimize the latency and then compensate internally to the worst case (Auburn Sounds, Voxengo... and probably others).

---

VST3

Is it unknown to us how much VST3 hosts like this dynamic latency thing, however the standard allows to do it at play time setupProcessing. I guess we could try make some parameter call _handler.restartComponent(kLatencyChanged); if they change latency, but as noted later, users would probably not like it.

---

AU

Audio Unit allows latency change pull-mode from the host with the property kAudioUnitProperty_Latency, listeners, etc. Reajusting is relatively inaudible in Logic, I don't rememember for other hosts but at least it compensated. Unknown how much dynamic that can be.

---

AAX

Very clear documentation on this one (cannot reproduce here). virtual AAX_Result AAX_IACFController::SetSignalLatency In short:

• you can request a latency change, seemingly at any time
• plugin then receive a notification when this happens (unknown if this happens while transport is playing, like Logic)
• again, recommendation that a parameter that changes latency is non-automatable

---

LV2

No investigation yet

---

Voxengo described how they do:

• dynamic latency change for AAX and AU
• worst-case latency for VST2 and VST3

[p0nce]

SDRR does dynamic latency change that depends upon an automatable parameter ("HQ".) Latency is not pessimized, will return 0, 4 or 22. How it works in reaper is that the PDC is updated on play, in VST2! Interesting.

EDIT: some plugins like Nova go as far as displaying "Latency has changed" warning so that the user stop and play transport.

[p0nce]

Would be super cool, but needs a way to report latency from any place.