I don't suppose anyone has a comprehensive summary of how this is handled by the various hosts?
The JUCE documentation rather enthusiastically encourages it to be called whenever latency changes. But there are discussions online about how infrequently hosts actually respond to any changes. And my brief experimentation suggests there are issues.
I've written a plugin which changes from 0 latency to 20ms when an option is selected. However instanting two of the plugins in Logic by inserting one, changing the setting and then duplicating the track results in the two tracks playing out of time. And as Jules notes it's pretty hard for a host to adjust the latency in realtime.
However, Shifting track delays is the cause of studio nightmares! So it'd be good to have an approach that didn't result in any uncertain behaviour.
I do need to set the latency based on the sample rate, otherwise users of 44.1khz audio are going to be living with a long delay designed for 192khz users (probably a small group admittedly - but undoubtedly fussy customers). So I'm going to try popping a call into prepareToPlay as well..
Any clues as to what definitely works would be greatly appreciated!
What setLatencySamples does
Calls to setLatencySamples perform two actions:
(1) store the latency in the AudioProcessor object. The host can called getLatency at any time to find out what this stored value was.
(2) call or set API specifics. These are:
VST(2) setIntialDelay sets a value in the cEffect structure. JUCE then calls a couple of change notification routines...
AudioUnit: calls PropertyChanged (kAudioUnitProperty_Latency, kAudioUnitScope_Global, 0);