Bug in AudioProcessLoadMeasurer (underreports load)

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 processBlock:

juce::AudioProcessLoadMeasurer::ScopedTimer s (measurer, buffer.getNumSamples());

To avoid too much overhead, maybe msPerSample could be stored instead/in addition to msPerBlock.

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…

2 Likes

Thanks for this suggestion, it’s implemented here:

2 Likes

Thanks so much @reuk — this is great!