For a small project, I have to continuously break down an audio signal into its frequencies (FFT). The ESP32 is ideal for a portable device because of its price and its low power consumption. The problem with a single-thread solution is that while the FFT is running, the audio signal cannot be sampled. On the ESP32, the FFT with 1024 bins takes at least 33 milliseconds, so many samples are lost. Since it's a measurement signal, that's not a good thing. So what could be more useful than using the two cores of the ESP32. I thought so: Sampling runs on core 1 and FFT runs on core 0. While the samples are being written to buffer A, the FFT runs with buffer B. When the FFT is finished, the buffers are swapped, and so on vice versa. The FFT already works and creating threads is no problem either. What I have not yet found out despite research on the Internet is how and where I have to declare the buffers. Have read something about "Ques" and "shared memory". I don't want to work with Ques, but "shared memory" sounds good. I am also familiar with the general problem of shared memory (read / write conflicts, etc.), but I can manage that. It's all about the declaration of the buffer. Does anyone have any experience?
Are global variables available to both cores ?
protolus: While the samples are being written to buffer A, the FFT runs with buffer B. When the FFT is finished, the buffers are swapped, and so on vice versa.
aka Ping Pong buffering.
What sets the sample rate? No matter how many cores you uses, the FFT must be fast enough so that its work is done by the time the sampling core fills its buffer for the next iteration.
Semaphore or mutex seems like a good place to start.