I’ve been cooking up a tiny utility plugin that simulates dsp load to diagnose and document some strange Logic behavior (In Logic 10.6.3, the “Audio” meters overreport load and behave non-linearly).
While digging in, I noticed what I think is a conceptual flaw in
AudioProcessLoadMeasurer: It’s built to calculate the load of a scope against the maximum block size (set once in something like
prepareToPlay) and doesn’t take into account the actual block size of the scope being executed.
This means any time the block size varies,
AudioProcessLoadMeasurer will underreport load (in some cases dramatically, for example if the current block is 10 samples vs. a max of 512).
In the wild, smaller block sizes likely have higher proportional overhead (i.e. a chunk of processing that happens once per block).
AudioProcessLoadMeasurer will currently swallow those peaks.
To fix while maintaining backwards compatibility, it might be nice to add a constructor that takes a block size, enabling people to do something like this in
juce::AudioProcessLoadMeasurer::ScopedTimer s (measurer, buffer.getNumSamples());
To avoid too much overhead, maybe
msPerSample could be stored instead/in addition to
My current workaround is to call
measurer.reset with the current block size before using the scoped timer, but it’s a bit heavy handed…