FFT sizes greater than 512 cause the Teensy to crash.

[ReeceKetley]

When using the formant shifter setting sample size greater than 128 (256) which equates to 512 in the FFT size the Teensy crashes when trying to create the FFT object?

This is on a teensy 4.0 oveclocked to 712mhz

Is 512 the max I can get?

[chipaudette]

Hi Reece,

Due to constraints on how the Teensy Audio Library / Tympan_Library processes audio, you are forced to do an FFT (of whatever length) every time an audio block fills. By default, the audio block length inherited from the Teensy Audio library is 128 points long (per channel). If you use my Tympan FFT routines with an overlap of 75%, your maximum FFT size will indeed by 4*128 = 512 points. So, you can't go longer than this as long as your block size is only 128 points.

There are two solutions to you to get you more FFT resolution:

• If you need finer frequency resolution (hence a longer FFT) but you don't care about the higher audio frequencies, you can simply use a lower sample rate with the same 512-point FFT. If you use halve your sample rate, then your 512 point FFT will have twice the frequency resolution! Easy!

• Or, you can adjust the audio block size to change your FFT resolution. Historically, due to limitations in the Teensy Audio Library, you could not go longer than 128 points, which means you could not have an FFT longer than 512. But, in Oct 2023, I made improvements to the Tympan_Library to enable a block size longer than 128 points. This means that you can also now have longer FFTs. Per this Tympan Example you can set a longer audio blocks simply by changing the line const int audio_block_samples = 128 to a longer value like const int audio_block_samples = 256. If you use a block size of 256, this makes your maximum FFT be 4x256 = 1024.

Even with these longer audio blocks, the Tympan_Library is still dependent upon the FFT quirks inherited from the Teensy Audio Library, which are somehow related to how they included the FFT functions from the ARM CMSIS libraries. I think that the maximum FFT size ends up being something like 4096 points, but I'm not sure. Beware!

If you still have trouble, please post a link to your code and I can maybe help you.

Chip

[ReeceKetley]

Hi Chip,

Thanks for the quick response! Ultimately, I'm trying to increase the quality of the formant shifting, which after some tweaking I have managed to staying within the 128 point restriction.

The formant shifter is to be used with only vocals, I was getting this weird aliasing, which I assumed was the FFT size. Anyway one of the solutions I came up with was to shift the frequency bands I'm processing (i.e. not from 20hz-20k) and only process where the vocals sit which has given me more bins which seems on the face of it to have made a difference.

Whenever I tried to set audio_block_samples higher than 128 points, it would just flat out crash when trying to create the FFT. But your explanation has cleared that up! Tympan Library is something I never stumbled across, I may need to check that out!

[chipaudette]

Oh, this is the OpenAudio library! Sorry! I got confused. I thought that you were posting on the Tympan_Library.

I created OpenAudio library first and then I created the Tympan_Library second. The OpenAudio library was then picked up and maintained by others (still in my GitHub account). So the two libraries share a lot of DNA, but each has had new developments that are independent of each other.

It's all confusing...even to me!

[boblark]

I was pawing through the issues and see this is open. Chip, I sorta thought of the OpenAudio objects that you created, like formant shifter, as still being yours? That said, I guess I have done trivial corrections to some of your stuff, as well. I don't see any problems with a fuzzy division of efforts. But, it is still your library and your call!! Bob

[chipaudette]

Bob, what kind of fix should be done for this? It's a known limitation of all the frequency-domain examples that the max FFT size is 4x whatever is being used for the audio block length. Since the max audio block size is 128, the max FFT size is 512. It's inherent in the design and not an unexpected bug.

So, without re-engineering to remove the 4x limit (or the 128 block size limit), there's nothing to do to actually fix the problem. I suppose that we could at least try to make it fail less hard? What might you suggest?