Could it be possible that AudioProcessorGraph will be updated to support the utilization of multiple CPU cores for audio processing?
This is a vital feature for hosts that manage multiple heavy AudioPluginInstance plugins.
Alternatively, it would be great to add it for the AudioPluginInstance processing, at least.
I’m working on the host application and
Currently, I am experiencing audio glitches when using only 8 plugins with a 256-sample buffer at 48000Hz with built-in audio (MacBook M1 pro, 16GB). This is due to the fact that only 1 single core is utilized for processing.
As a reference, I have used Reaper, which begins to produce glitches with the same 16 plugins using a 64-sample buffer at 48000Hz.
Single-threaded processing is generally a host limitation, not a limitation of the plugin’s implementation. No plugin formats that I’m aware of except for CLAP support multi-threaded rendering, and even then that’s only possible if the DAW implements CLAP’s multithreading model.
EDIT: This of course doesn’t limit the possibility of the audio graph being multithreaded, but it’s a big enough lift that I don’t know if it’d be done in any reasonable amount of time for you to use it.
If you have an algorithm that would benefit from multithreading (and beware; the construction/teardown of threads can be expensive enough to make this impractical), you could implement your own multithreaded implementation. I’d recommend using a threadpool for this. In pseudocode:
// In your plugin's main processBlock
// Assume some functions expensiveAudioTask* exist and contain high-cost DSP
tp = Threadpool()
t1 = tp.start(expensiveAudioTask1);
t2 = tp.start(expensiveAudioTask2);
t3 = tp.start(expensiveAudioTask3);
// Do some other work on the main audio thread here
t1.join()
t2.join()
t3.join()
I’ve never attempted to multithread my DSP and would be hesitant to do so. You’d need multiple highly expensive jobs for it to be worth it IMO, and thread spawning can be a little too non-deterministic for realtime. That said, if your algorithm does consist of multiple expensive and fully parallel jobs, go for it. I’m sure it’ll be a fun project!
The original poster is exactly asking about a hosting side implementation, not how to do it within individual plugins. (AudioProcessorGraph, not plain AudioProcessor.)
In CLAP, the plugin internal multithreading also relies on the host being able to implement the thread pool/parallel for loop, the plugin format itself doesn’t provide the implementation.
Apologies, that wasn’t clear to me given the original wording. I’m aware that CLAP’s thread model is only enabled if the host implements it but I’ll edit my post for clarity.
Thanks for getting back to me! I’m actually working on the VST Host app, not the plugin. Sorry if that was unclear in the topic description.
As for plugins, I’m using Zenology, Kontakt, and Triton instances to handle them in my host app.
And yes, I’ve definitely run into this «host limitation» in my current development.
My bad! Gonna have to practice my reading comprehension
My team has a partially customized version of the JUCE graph, but we use it for managing a large array of nodes within a single plugin. Forking JUCE and implementing the threading yourself could definitely be an option, though it could be harrowing! Good luck and definitely share your results if you end up going that route.
That’s all right, I have updated the topic description to enhance its clarity.
I have attempted several temporary quick-and-cheap solutions to make the application multi-core compatible, some of which were partially successful in utilizing all available cores, while others were not. However, all of these solutions resulted in distorted sound due to lack of proper synchronization of the buffers and streams.
For now, I have shelved my attempts to achieve that. When I have completed the development of the main functionality, I will revisit it. I hope that by then, there would be some improvements in the JUCE core.
Thank you for sharing your code. It was a great starting point for me. However, as you mentioned, it’s quite outdated, and there’s almost nothing relevant to the latest Juce logic.
My current hope is that the community will vote for this feature, and the Juce core team will consider it for future developments.
Sorry if that was unclear in the topic description.