@clevername27 said in All About Latency:
Is the idea that if you reported your latency correctly, the scheduler would be sample-accurate? If so, given that it's impossible to measure a plugin's latency, how do we know if the scheduler works?
Yes. While playing back audio, a properly functioning DAW will take into account PDC for each track and then play back first the track with the most delay, then play others so that they're all matched up. In Reaper, you can view PDC for each track in the Performance Meter window. You can even see it change based on the HISE's method call to report the latency.
To check that it works, have a plugin that simply delays the audio for a given value. Create a knob, and add a callback that reports the latency based on the current knob value x current sampling rate, then set the delay. You can use the stock delay node in ScriptNode.
Now create a track, add an audio file, duplicate the track and put the plugin on one of the tracks and invert the phase on it. Now hit play and adjust your knob for the delay. No matter what you set it to, you should be getting a silence (except for a few moments while turning the knob during playback where there's a mismatch between the reported delay being adjusted by the DAW and the delay node reacting instantly).
@clevername27 said in All About Latency:
I mean that a if plugin is performing a non-constant-time operation (O1 complexity), then the amount of time the DSP code takes to execute may vary, meaning the audio output may gets written later in the buffer (or the next buffer)?
Aren't all realtime audio operations like that? That's what the buffer is for. Even if you're overflowing the buffer, you'll get audio breaking up but an offline render will still render the audio correctly in sync.
