q15 fft

[giuliomoro]

According to the docs, no rescaling is performed when operating the integer-valued fft https://www.keil.com/pack/doc/CMSIS/DSP/html/group___real_f_f_t.html#ga053450cc600a55410ba5b5605e96245d

// forward fft
int forward = 0;
arm_rfft_init_q15(&instance, len, forward, 1);
arm_rfft_q15(&instance, (int16_t*)in.getData(), (int16_t*)out.getData());

gives the value of the fft divided by the number of elements.

According to the table in the docs this has to be interpreted as a fixed-point integer of format log2(size).(16-log2(size)), while the input is interpreted as 1.15.

Experimental measurements show that these values are correct.

[giuliomoro]

It took a second once I was able to printf.

bea2da563b633884f12a80836127853540fd7c7f including matlab example

With a typical musical signal, what happens is:

• you first transform to the frequency domain. It works pretty nice, some small rounding errors. But at this point your signal will probably have small amplitudes everywhere.
• when you do the ifft you start from a signal that is very small, using only a handful of the 16bit you have available, therefore the result of the ifft is pretty distorted. By definition of how the CMSIS functions are implemented, you will then have to << log2(fftSize) your result to go back to 1.15
• if you are brave, you could normalize your frequency domain signal (between fft and ifft), by << (16 - log2(data.getMaxValue()), but this will most likely cause clipping when you apply the ifft.

Conclusion: q15 fft is probably good only if you do not need to do fft/ifft. For instance, if you are only analyzing something in the frequency domain (e.g.: find the spectral centroid), it could be good enough.

[pingdynasty]

done in ShortFastFourierTransform