Could the AudioAnalyzeFFT256/1024 not be subclasses of a generic FFT class, able to handle a wider range of powers of two?
I was looking at the implementation using arm_cfft_radix4_q15, whereas the fastest method seems to be arm_rfft_q15
as only real values are fed to the FFT? I benchmarked rfft as faster than cfft on Teensy 4.0 by about 50% - although it may be less
numerically accurate due to the pre- and post-processing.
The arm_cfft_radixX_XXX functions are also deprecated, according to the documentation I found. The other methods like
arm_cfft_q15 and arm_rfft_q15 allow powers of 2 for FFT size, not limited to powers of 4.
The implementation of window functions as precompiled tables becomes an issue with this, if you want to support 32/64/128/...../4096/...
sizes you'd need to be able to generate them at runtime for the windows/sizes used.
I note the existing tables are wasteful of space in that they don't take advantage of the even symmetry of a window function.
They are also not DFT-even style which may cause some issues in some contexts.
And lastly the window functions aren't structs/objects so there's no record of their noise bandwidth factor which is needed
for measuring noise rather than signal peaks.
I was looking at the implementation using arm_cfft_radix4_q15, whereas the fastest method seems to be arm_rfft_q15
as only real values are fed to the FFT? I benchmarked rfft as faster than cfft on Teensy 4.0 by about 50% - although it may be less
numerically accurate due to the pre- and post-processing.
The arm_cfft_radixX_XXX functions are also deprecated, according to the documentation I found. The other methods like
arm_cfft_q15 and arm_rfft_q15 allow powers of 2 for FFT size, not limited to powers of 4.
The implementation of window functions as precompiled tables becomes an issue with this, if you want to support 32/64/128/...../4096/...
sizes you'd need to be able to generate them at runtime for the windows/sizes used.
I note the existing tables are wasteful of space in that they don't take advantage of the even symmetry of a window function.
They are also not DFT-even style which may cause some issues in some contexts.
And lastly the window functions aren't structs/objects so there's no record of their noise bandwidth factor which is needed
for measuring noise rather than signal peaks.