I’m developing an audio plugin (VST3) in JUCE that I’ve been testing in Dorico and noticing some extremely strange behaviours related to the device buffer size. It seems to me that the buffer size is not respected at all and always defaults to 512 on playback, independently of what I set it to in the Device Control Panel:
I’ve tried this with multiple devices (MOTU UltraLite mk5, Focusrite 2i2, headphones, built-in, Blackhole) and multiple different values for the buffer size, but the buffer size provided by JUCE’s AudioProcessor::prepareToPlay and the buffer size of the provided audio buffer in AudioProcessor::processBlock always seems to default to 512.
Could it be that I’m doing something wrong, or is the buffer size setting actually ignored here?
If needed, I can provide you with a minimal plugin for testing the buffer size!
I’m running Dorico 5.1.60.2187 (I can update to 6 if needed) on MacOS 15.2 (MacBook Pro 14" 2023 / M2 Pro).
Interesting. And the CoreAudio Device Settings show a different buffer size than what you see elsewhere?
Yes, please, send me your plug-in and we’ll have a look. Does that plug-in only run in Dorico or also in Cubase or other DAWs?
You can send to u dot stoermer at steinberg dot de
Thanks
I apologize for the late reply, I sent the mail just before I went on vacation and then forgot about it.
Yes, the plugin should run in any DAW, I’ll send you a separate mail with the details!
Most DAWs have their own interface for setting so comparing the settings in Dorico with other DAWs isn’t really meaningful. Just a few examples from the environments I regularly use:
Thanks for the plug-in, I succesfully installed it now and quite to your surprise - I guess - I have to report you, that everything is normal what you see.
How come?
Well, the reason is ASIO-Guard. I suppose you don’t have Cubase because there you can see this all more clearly.
To start explaining from the beginning, one has to know about the Cubase audio engine, because also Dorico’s audio engine is directly derived from that audio engine.
Some 13 years ago we introduced ASIO-Guard in Cubase 7. The internal name for this was (and still is) Prefetch Processing. The idea behind that is, if in a DAW you only play back a piece then you can “look into ahead into the future”, namely prefetch more and bigger buffers and process them already way ahead of their real scheduling on the timeline. This helps easing out and flattening the average audio engine load, which results in a much better performance and therefore less risk of running into drop out situations.
Coming back to the buffer sizes that you see: Dorico’s audio engine also uses ASIO-Guard, though you can also switch it off in the Dorico Preferences, but unlike Cubase there is no GUI where you can interact with the ASIO-Guard settings. You can change the value by editing some XML file, but it’s rather tedious and error prone. In Dorico by default ASIO Guard Level is Medium , and that results in those 512 samples,. If you’d set it to Low, it becomes 256 or even 1024 when used with Large buffersize.
I’d recommend to get a Cubase trial version, because there in the Studio Setup you have a full GUI for ASIO-Guard settings, so you could try out there and also play with the values, you can then immediately see how applying changes in some values, can have a big impact on the used buffersize. E.g. if one channel goes into live mode or record enable, then you can see buffer size dropping to the value has in the Device Control Panel. Another parameter that has an influence is the Multi Processing flag..
As said, also in Dorico you can change all those values, but you have to know where to find them in the defaults or preferences.xml and you have to restart Dorico in order for them to take effect. Cubase on the other hand has an Apply button so you can immediately see/hear the result.
I don’t know, does my explanation make sense? As I said, probably it’s best to get a Cubase trial and play around with it, then most likely you will understand.
Thank you so much for looking into this and for sharing this information!
In my case, simply disabling the ASIO Guard solves the issue. I’m using Dorico to send MIDI to a real-time generative framework, where I need more detailed transport info than what MTC can provide (I need tick, bar, meter, etc.), and afaik, the only way to access this information in Dorico is through the AudioPlayHead class in a plugin, which can only be accessed from the processBlock function.
So, in my case the buffer size doesn’t just control the latency of the audio rendering, but effectively also the update interval of the generative framework’s transport state, and the default 512/48k (~10.6 ms) is too inaccurate timing-wise. But since I’m not rendering any audio directly in Dorico, audio dropouts in Dorico is not an issue, which means that disabling the ASIO guard is a perfect solution here!
I hope that there will be means to continuously poll (and ideally control) the state of the transport through lua scripting in the future, once you introduce more elaborate scripting in Dorico. But in the meantime, this will work perfectly as a workaround!
Just in case you haven’t read or figured this out yourself, Dorico currently doesn’t send tempo changes to VSTs, only the initial tempo AFAIK. So bpm from AudioPlayHead::CurrentPositionInfo will only give you that initial value correctly. If you even care about the bpm, of course…
The missing tempo information isn’t much of a problem in my case since I only care about relative timing (ticks, beats, bars, not seconds), but I noticed that the same issue applies to meter changes, which effectively means that there’s no way to compute the current beat / position in bar.
@Ulf is there any chance that this could be provided in future versions of Dorico? I’d be happy to provide a new plugin to test how meter/tempo changes are passed to the plugin!
Echoing @jborg, tempo synchronisation is high on my list of desired playback enhancements. I have my fingers crossed that a future version will include this functionality.
