Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 2 of 2

Thread: Genericize FFT? Also window functions representation

  1. #1
    Senior Member
    Join Date
    Jul 2020

    Genericize FFT? Also window functions representation

    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.

  2. #2
    Senior Member
    Join Date
    Jul 2020
    [ I've noticed there's already an outstanding pull-request for the deprecation issue, (though it misses fft256). ]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts