FFT - some observations

[perlix]

Using the MultiOutput class, I managed to visualize played audio in a 32-bins frequency spectrum on a TFT dislay.
Perhaps my observations regarding the AudioRealFFT class and the two suggested alternative libraries could be helpful to others.

1. When using AudioRealFFT together with WiFi, I had to put #include "AudioLibs/AudioRealFFT.h" after the line that establishes the WiFi connection (in my case: ICYStream urlStream(wifi, password); ), otherwise WiFi wouldn't connect.
2. Using AudioKissFFT instead of AudioRealFFT produced much lower magnitudes overall, so it needed different scaling on the display. Also, this lib appears to consume more cpu time.
3. Using AudioESP32FFT worked similarly to AudioRealFFT. I just had to rename the object, as this lib already uses 'fft' internally.

That said, the 'player-url_icy-i2s' example with added code for a display works perfectly now and I'm impressed by how this library's modular design made it all so simple!

---

Tested with latest commit of all used libraries.
Arduino IDE version: 1.8.19.
Arduino-ESP32 package version: 1.0.6.
Hardware: TTGO-TM-Music (ESP32 with built-in PCM5102 DAC and ST7789 TFT display).
Selected in IDE: ESP32 Dev Module, PSRAM Disabled; Partition: Huge App.

[pschatzmann]

I don't think there is any issue that is asking for a change of code.

I will add a link to your comments to the FFT Wiki

[RWBRWB]

Using the MultiOutput class, I managed to visualize played audio in a 32-bins frequency spectrum on a TFT dislay. Perhaps my observations regarding the AudioRealFFT class and the two suggested alternative libraries could be helpful to others.

1. When using _AudioRealFFT_ together with WiFi, I had to put  `#include "AudioLibs/AudioRealFFT.h"` after the line that establishes the WiFi connection (in my case: `ICYStream urlStream(wifi, password);` ), otherwise WiFi wouldn't connect.

2. Using _AudioKissFFT_ instead of _AudioRealFFT_ produced much lower magnitudes overall, so it needed different scaling on the display. Also, this lib appears to consume more cpu time.

3. Using _AudioESP32FFT_ worked similarly to _AudioRealFFT_. I just had to rename the object, as this lib already uses 'fft' internally.

That said, the 'player-url_icy-i2s' example with added code for a display works perfectly now and I'm impressed by how this library's modular design made it all so simple!

Tested with latest commit of all used libraries. Arduino IDE version: 1.8.19. Arduino-ESP32 package version: 1.0.6. Hardware: TTGO-TM-Music (ESP32 with built-in PCM5102 DAC and ST7789 TFT display). Selected in IDE: ESP32 Dev Module, PSRAM Disabled; Partition: Huge App.

@perlix I'm also trying to display a 30-40 band spectrum for the audio playing on a LCD display while using Phil's web radio streaming library.

I already have the web streaming working perfectly so I just need to add this AudioRealFFT library & feed it the audio data that the web radio stream is providing.

Are you able to share your code so I can see how you accomplished it and then I can convert to work with my LCD?

I'm sure it's easy but I learn quickly by just looking at examples so if you can share what's working for you that would be awesome.

Thanks!

[StuartIanNaylor]

@pschatzmann there are two other FFT libs that crop up quite often for optimised FFT and that is https://gitlab.mpcdf.mpg.de/mtr/pocketfft and for more complex started seeing https://github.com/Themaister/muFFT crop up

Also with FFT and DSP with the vector instructions of the esp32-s3 how well did Esspressif manage to optimise there libs.
Would love to see how a s3 optimised pocketfft compares against https://github.com/espressif/esp-dsp

https://docs.espressif.com/projects/esp-dsp/en/latest/esp-dsp-benchmarks.html

I am not even hacker level but a did molest some existing C code to create an also based realtime GCC-PHAT delay sum beamformer.
https://github.com/StuartIanNaylor/ProjectEars/tree/main/ds

Its pretty awful the way it strips out the interlaced channels rather than just have a more complex pointer function but after some screaming of creating the cyclic buffer including the margins I was extremely happy to halt there.
I wonder if GCC-PHAT would port and be a good example?

[pschatzmann]

Feel free to make a comparision or extend my library with your preferred implementation.
I am already providing 4 alternatives as you can find in https://github.com/pschatzmann/arduino-audio-tools/wiki/FFT

[StuartIanNaylor]

Ooof no as still recovering from my 1st C hack :) PocketFFT seems to of gained choice by a lot of the ML libs but prob would use the esspressif FFT as its optimised for the S3. I might try benching a S3 with what you have provided.

[pschatzmann]

Since the Espressif DSP Library is part of Arduino now, I have also added an implementation which uses this functionality:
see FFT Wiki. In a nutshell: I did not see any performance advantage compared to the other libraries.

I had a quick look at your suggested pocketfft. It uses doubles, so expect it to be much slower then all other provided implementations!

[StuartIanNaylor]

Espressif DSP Library is only of interest with the S3 vector instructions https://docs.espressif.com/projects/esp-dsp/en/latest/esp-dsp-benchmarks.html
Also only a selection are optimised but what could be common for audio such as

FunctionOptimization	ESP32O2	ESP32S3O2	ANSIO2	ESP32Os	ESP32S3Os	ANSIOs

FFTs 16 bit Fixed Point
dsps_fft2r_sc16 for 64 complex points	8786	933	14575	8786	793	15861
dsps_fft2r_sc16 for 128 complex points	20214	1734	33121	20214	1627	36238
dsps_fft2r_sc16 for 256 complex points	45755	3507	74290	45755	3430	81638
dsps_fft2r_sc16 for 512 complex points	102208	7312	164803	102416	7311	181758
dsps_fft2r_sc16 for 1024 complex points	225862	15641	362193	225861	15640	400853

Yeah should of realised as PocketFFT seems to get preference as CPU vector instructions of things like AVX / Neon and not really mcu focussed.
Cheers for having a look though.

Prob again limited interest but looking at implementing a TF4Micro KWS on a S3 which 16bit audio and the ML should benefit.