Performing a 960-point FFT (non-power-of-two) on XMOS

[yako]

I’m currently integrating the XMOS DSP FFT interfaces into my application, but I’ve run into a challenge:

I need to compute a 960-point FFT on a real-time audio stream sampled at 48 kHz.

Issue with built-in APIs: The XMOS bfp_fft_forward_mono routines only accept lengths that are powers of two. I’ve tried zero-padding my 960 samples up to 1,024, but this changes the frequency bin spacing from exactly 50 Hz (48,000 Hz / 960) to 46.875 Hz (48,000 Hz / 1,024). Since I’m subsequently calculating Bark-scale band energies, the mismatch between the padded FFT bins and the original 960-point grid introduces errors in my Bark band assignments.

I’m looking for any examples, reference code, or recommended approaches that would allow me to perform a true 960-point FFT (or another non-power-of-two length) on XMOS hardware. In particular:

Has anyone implemented a Bluestein (chirp-Z) or mixed-radix FFT on XMOS?

Are there community-provided libraries or snippets that show how to compute arbitrary-length FFTs without zero padding?

Thank you in advance for any pointers or code samples. I’d be grateful for any guidance on how to handle non-power-of-two FFTs efficiently on XMOS.

[fabriceo]

hi, upsampling every 15 samples to 16 could be an option to use the 1024 pt algorithm , just discarding the 64 upper bins.
the quality of the upsampling process here depends on the final precision expected...

[yako]

Hi Fabriceo,

Thanks again for the suggestion. My concern is that by up-sampling from 960→1024 samples and then running a 1024-point FFT, the bin spacing shifts from 48kHz/960=50Hz/bin to 48kHz/1024≈46.875Hz/bin.

Originally, all my Bark-scale band edges were defined on that 50 Hz grid of the 960-point FFT. Won’t this change in FFT length break my existing band assignments?

How would you recommend mapping the 1024-point FFT output back onto the original 960-sample/Bark-band layout so that each band’s energy stays consistent? Should I simply re-compute my Bark boundaries on the new 46.875 Hz grid, or is there a bin-grouping or interpolation strategy you’ve found that preserves the original 50 Hz-spaced Bark bands?

Thanks for any pointers!

[fabriceo]

Hi Fabriceo,

Thanks again for the suggestion. My concern is that by up-sampling from 960→1024 samples and then running a 1024-point FFT, the bin spacing shifts from 48kHz/960=50Hz/bin to 48kHz/1024≈46.875Hz/bin.

well, if you resample by producing 16 samples out of 15 it is like sampling at 51200 instead of 48000 and 51200/1024 = 50hz but you don't need the bins 961..1024
now resampling 15 to 16 samples might be more or less complex depending on the precision you need

[yako]

Thanks for your suggestion! I noticed that XMOS provides two built‑in sample‑rate conversion APIs—SSRC (Synchronous Sample Rate Converter) and ASRC (Asynchronous Sample Rate Converter).

For my use case , would you recommend using one of these interfaces directly? Or is there a better way to achieve that exact 16/15 resampling on XMOS? I’m not very familiar with how to use SSRC and ASRC ==.

[Ross]

Asynchronous sample rate conversion is a more complex challenge compared to synchronous conversion. You only need to use an ASRC when the input and output audio sample rates are driven by independent clocks that are not synchronised or related by an exact rational ratio i.e. it allows conversion between two clock domains.