fft ifft ?

Status
Not open for further replies.
Just as a guess, in many practical engineering applications of the FFT you really only care about the amplitude of the (real) power spectrum. You don't want the additional memory space and data structures to deal with phase, negative frequencies or imaginary values.
 
I want to do more than just display a spectrum on a lcd
I use puretdata so far and no way you could do ifft without the real/img data

the magnitude/phase , for my needs, is useless (besides, afaik, fft in teensy audio library does not contain the phase, and there is no ifft either)

I modify the spectrum, then go back to time domain and create really cool effects that way

the very base of DSP
 
not if you do ifft afaik

JBeale gave you the real practical answer ("why there were no ifft in teensy ")

The technical answer is, the audio library that implements the FFT functionality is running on 16 bit
There is no convincing argument to do FFT based filtering (fft-ifft) on 16 bit.

However, nobody prohibits to take the existing code and to implement either 32 bit fft/ifft or even float fft/ifft code.
after all the fft implementation is based on CMSIS code, which provides also 32-bit or float versions.
 
...so I was wondering why there were no ifft in teensy ?
and why is the fft in teensy not giving real/img part ?

Could you be more specific about the "fft in teensy" you're mentioning?

In the audio library, the FFT object gives only magnitude. It's intended for music visualization.

In arm_math.h (an older version of CMSIS-DSP), which is used internally by the audio library and also available to you if you include arm_math.h, the FFT functions do process complex numbers for input and output. It does indeed provide inverse FFT.

So it really does matter which code. Please be more specific.
 
Could you be more specific about the "fft in teensy" you're mentioning?

In the audio library, the FFT object gives only magnitude. It's intended for music visualization.

In arm_math.h (an older version of CMSIS-DSP), which is used internally by the audio library and also available to you if you include arm_math.h, the FFT functions do process complex numbers for input and output. It does indeed provide inverse FFT.

So it really does matter which code. Please be more specific.

ok, then awesome, I'll have a look
sheers mate
 
??? what ?? why ?
most wav samples are 44khz 8/16 bits

most MCU ADC are 12 bits

what does this have to do with anything ?

It is all about integer arithmetic (i.e. not floating point) using optimized DSP engines

a 1024 fixed point FFT must shift the results (scales) by 10 bits to the right ( so you loose up to 10 bit resolution in your input data)
an additional 1024 fixed point IFFT shifts the results again by 10 bits to the right.
see also https://www.keil.com/pack/doc/CMSIS/DSP/html/group__ComplexFFT.html

So doing 16 point arithmetic (as done in audio library) you shift all weak details into nirvana and keep only strongest signals.

IOW: the fixed point implementation FFT and IFFT divides always by the number of samples, so IFFT (FFT (x)) will not be x but x/N !

If you are interested in FFT-based filtering, you must use at least 32 bit FFT , which on Teensy with optimized 16 bit DSP arithmetic is significantly slower, but it can and has been done and presented here on the forum
 
Hi Phil,

it would be nice to know more about your project.

I modify the spectrum, then go back to time domain and create really cool effects that way

the very base of DSP

Really curious about your cool effects!

Here is the "very base of DSP" you need (FFT-iFFT chain) programmed by Brian:

https://forum.pjrc.com/threads/4384...ar-cabinet-simulation-)?highlight=convolution

Instead of the complex-multiply of the FFT results with the filter mask (consisting of the FFT of the impulse response of the FIR filter) just add your effects.

Have fun with that!

Frank DD4WH
 
Hi Walter,

So doing 16 point arithmetic (as done in audio library) you shift all weak details into nirvana and keep only strongest signals.

Thanks a lot for that explanation! That is the first time I understand the underlying reason for this!

All the best,

Frank DD4WH
 
I've been using the CMSIS Version 5.3.0 DSP Library since May 2018 (see github.com/ARM-software/CMSIS_5). I might be the only person on this forum using it. The library allows me to use the 32-bit floating point capability of the Teensy 3.6. I have been able to use it in real-time with 16-bit sample rates out of both ADCs up to around 450 kHz (i-q data). I'm very happy with the performance I am obtaining. Here is the FFT/IFFT performance I am getting with the library:


# PointsForward rfftInverse rfftForward cfftInverse cfft
512201 us247 us239 us294 us
1024362 us454 us588 us714 us
2048846 us1066 us1376 us1620 us
40961860 us2304 us2504 us2990 us
 
Last edited:
Hi Willie_from_Texas, what system clock rate are you using to obtain those numbers? At first glance they seem impressive.
 
These results are at the default clock rate of 180 MHz. I'm running in real-time using data from the ADCs. I'm concerned that if I overclock the chip it will affect accuracy of the ADCs. - W
 
Chip also did a detailed comparison and speed test with Teensy 3.2 and 3.6, measuring differences between integer and floating point processing and the CMSIS DSP functions:

http://openaudio.blogspot.com/2016/10/benchmarking-teensy-36-is-fast.html

Given the date of 2016 I'm willing to bet this benchmark was done using CMSIS Version 4. The article doesn't state whether or not the FFTs were calculating real or complex data. Assuming real floating point data using an FFT size of 512, the results I obtained are about twice as fast. It would be an interesting comparison for someone running Version 4 to duplicate the cases that I published in the table from my earlier post. -W
 
Status
Not open for further replies.
Back
Top