Hi all,
I’ve read that using AudioProcessorGraph is not recommended in cases where the graph is not supposed to change at runtime. What’s the best way to set a static chain then ? It’s unclear to me. I’ve been using juce::dsp::ProcessorChain so far, but in the end it doesn’t seem to be so standard and is a bit of pain now because I’m trying to include some components that were already written as AudioProcessors in the first place.
Thanks in advance!
juce::dsp::ProcessorChain is the best bet for performance, because it can be optimised at compile time.
You will not be able to get that performance with juce::AudioProcessor because of the virtual calls.
However, the ProcessorChain is not suitable if your graph is not serial (hence chain).
You can still run juce::dsp::Processors e.g through a DryWetMixer, but that doesn’t happen in the ProcessorChain, but you call it manually in your processBlock() (pushDrySamples before running the processor or the chain, and afterwards the mixWetSamples.
TL;DR: if you can afford, rewriting the AudioProcessors into juce::dsp::Processors will help performance.
Alright thanks, very clear!
I know this is a bit dependent on what is in the chain, but do you have any rough estimations on what kind of performance improvements one should expect to see by going this route?
It’s going to be minimal. I’d focus on your inner sample loops as they can potentially run a lot depending on your process block size. A lot of DSP doesn’t need to run at audio rate so you can calculate every ‘n’ samples and interpolate in-between. Then use good faster math approximations. That kind of thing. These considerations will have a much bigger impact on performance.
!00% agree on what @Nitsuj70 said:
Optimisation always start from the inner to the outer, because the inner is called a multiple time of the outer.
Stuff that happens once per processBlock are of the least concern, although it depends on which block size the host is running.
