Confusion about FFT length and Max overlap

[neodog]

The manual has this to say about FFT length:

As the FFT length is increased the analyser starts to overlap its FFTs, calculating a new FFT for every block of input data. The degree of overlap is 50% for 16k, 75% for 32k, 87.5% for 64k and 93.75% for 128k.

And about Max Overlap:

The spectrum/RTA plot can be updated for every block of audio data that is captured from the input, overlapping sequences of the chosen FFT length. This can present a significant processor load for large FFT lengths. The processor loading can be reduced by limiting the overlap allowed using this control.

Is the overlap % the amount of the block overlapping, or is it % not overlapping? I ask because I get the slowest computations setting Max Overlap to 0%, and the fastest computations setting it to 93.75%; the values in between follow this pattern. This is exactly opposite of what I would expect: more overlap should mean more computations. It's almost as if the drop-down values have the reverse their intended ids.

 

[John Mulcahy]

More overlap means more frequent updates since fewer new samples are required to calculate the next FFT result.

 

[neodog]

Ah, of course, I wasn't compute-bound there, it just takes more time to fill out a 1M sample window.

So FFT Length and Overlap normally govern the frequency of update, determined by the duration of FFT_Length * (1-Overlap). And ideally, it seems that every sample gets processed in real-time on these intervals.

However, it seems that the smoothing algorithm has a significant impact on the update speed. No smoothing gets updates that match the FFT_Length * (1-Overlap) formula, but psychoaccoustic slows it down an order of magnitude. Is this compute-bound, then? Since it's not just affecting update speed, but the average count as well, it must mean that it is no longer processing samples in real-time at that point. That must mean samples get dropped, right? If so, which ones? At some point there would have to be a window without overlap integrity.

I might have hoped for a mode where samples are processed as quickly as real-time requires, but updates can be skipped if they fall behind. I see that the Update interval can be set as high as 4, but that's not enough to get any of the smoothing modes to collect averages as quickly as "no smoothing" would.

 

[John Mulcahy]

I can't follow the logic of combining a long FFT with heavy smoothing, but that is very likely to result in skipped sample blocks. The graph update is a negligible burden these days, the limit will be processing since the entire FFT length has to be processed to apply the smoothing. With a long FFT and high overlap that would be asking a lot since the smoothing has to run on a single core due to the recursive nature of the implementation.