I 'm not sure where to post this, but I'm very pleased with the results so far with testing FFT/IFFT processing using the 32-bit floating point versions of the arm_math Library and the Teensy 3.6 and its FPU.
Previously, passing audio through pairs of the q15 based arm_math library FFT/IFFT functions resulted in very noisy results, due to the limitations of the 16 bit depth. Using the arm_cfft_radix4_f32 as pretty much a drop in replacement for the arm_cfft_radix4_q15 function, the results are dramatically better.
For example with a 1024 FFT/IFFT length, artefact tone levels dropped from around -40/-45 dB to around -78dB. Base level white noise went down from around -63 dB at say 5KHz to occasional peaks of about -78 dB, mostly at much lower levels than that.
I have attached some Spectrographs of the FFT/IFFT reconstruction of a 1K Hz sine wave to show the differences, both at 1024 and 256 lengths. Note that so far there is no shaped windowing or overlapping etc done at all, so I'm hoping for some reduction in some of the artefact peaks on these graphs with some window processing.
Music played from iTunes through the FFT/IFFT pair at either 1024 or 256 lengths is quite acceptable for casual listening at least. There is certainly a slight increase in background hiss noticeable with more careful listening.
Now I'm ready to start with the timestretching, pitch shifting, sound tone freezing, sound blending across bins and … and …
I expect this will take a while to get together though. I am hoping it will be usable in a realtime performance context eventually.
For the graphs shown, the audio is played into Line-in on the Audio shield via a record 'queue' Library object , an FFT/IFFT is performed on it and then sent to Line-out via a play 'queue' Library object.
Measured Latency data -
1024 length FFT/IFFT passthrough: 29.57 ms (23.22 ms of that would be serialisation delay)
256 length FFT/IFFT passthrough: 12.15ms (5.8 ms of that would be serialisation delay)
For reference, for a 128 length Audio block passthrough via Library 'queue' objects without any FFT/IFFT processing, the latency measures as 9.25 ms (2.9 ms of that would be serialisation delay)
A big thanks to everyone who helped get me to this point, particularly DerekR and Duff. I suspect the next bits will be harder
Let me know if you have any questions.
Previously, passing audio through pairs of the q15 based arm_math library FFT/IFFT functions resulted in very noisy results, due to the limitations of the 16 bit depth. Using the arm_cfft_radix4_f32 as pretty much a drop in replacement for the arm_cfft_radix4_q15 function, the results are dramatically better.
For example with a 1024 FFT/IFFT length, artefact tone levels dropped from around -40/-45 dB to around -78dB. Base level white noise went down from around -63 dB at say 5KHz to occasional peaks of about -78 dB, mostly at much lower levels than that.
I have attached some Spectrographs of the FFT/IFFT reconstruction of a 1K Hz sine wave to show the differences, both at 1024 and 256 lengths. Note that so far there is no shaped windowing or overlapping etc done at all, so I'm hoping for some reduction in some of the artefact peaks on these graphs with some window processing.
Music played from iTunes through the FFT/IFFT pair at either 1024 or 256 lengths is quite acceptable for casual listening at least. There is certainly a slight increase in background hiss noticeable with more careful listening.
Now I'm ready to start with the timestretching, pitch shifting, sound tone freezing, sound blending across bins and … and …
I expect this will take a while to get together though. I am hoping it will be usable in a realtime performance context eventually.
For the graphs shown, the audio is played into Line-in on the Audio shield via a record 'queue' Library object , an FFT/IFFT is performed on it and then sent to Line-out via a play 'queue' Library object.
Measured Latency data -
1024 length FFT/IFFT passthrough: 29.57 ms (23.22 ms of that would be serialisation delay)
256 length FFT/IFFT passthrough: 12.15ms (5.8 ms of that would be serialisation delay)
For reference, for a 128 length Audio block passthrough via Library 'queue' objects without any FFT/IFFT processing, the latency measures as 9.25 ms (2.9 ms of that would be serialisation delay)
A big thanks to everyone who helped get me to this point, particularly DerekR and Duff. I suspect the next bits will be harder
Let me know if you have any questions.