To meet the project submission deadline, I decided to use the ESP-NOW protocol with Wi-Fi for the walkie-talkie project instead.

I still hope to try the nRF24L01 setup again later when I get a new set of ESP32 boards.

It would also be great if someone could successfully implement the nRF24L01 + ESP32 audio transmission project and share a working video on YouTube.

Using the ESP-NOW and wi-fi take a lot of current and while one of my board worked fine, the other board kept crashing at the point of wi-fi initialisation "brownout  detector was triggered " error. I had to add a 470uF capacitor to the 3.3v and GND of that board, and had to ignore the brownout error from the code for it to stabilise and run. 

But I don't know why the nrf24 is not transmitting and receiving the audio packet properly. 

Thank you @noweare for your response. 

I really wish I could get this nRf24 transceiver module to work 😣 

I will try to use the FreeRTOS Stream Buffer to see if it works. 

As for the power issue could it be because the capacitor isn't soldered to the nRF24 module VCC and GND Pins?

Although on the breadboard it is connected. 

Correction: Actually, the INMP441 outputs data in the high 24 bits of the 32-bit word. If you shift right by 8, you are leaving 16 bits of audio. However, standard I2S for this mic is often "Left Justified." If your audio sounds extremely quiet or like static, try shifting by 14 or 16, or masking the sign bit properly.

​3. The "Buffering" Strategy

​The START_THRESHOLD (2000 bytes) in your speakerTask is a smart move. It prevents "motorboating" (rapid clicking) caused by the speaker playing faster than the radio can deliver packets.

​⚠️ Potential Issues & Suggestions

​1. The "Ring Buffer" Race Condition

​You are using RingBuffer<uint8_t> rxRing(RING_BYTES);.

• ​The Risk: If this is a standard non-thread-safe buffer, you might experience memory corruption or crashes because radioTask (Core 0) is writing while speakerTask (Core 1) is reading.
• ​The Fix: Use a FreeRTOS Stream Buffer (xStreamBufferCreate) instead. It is designed exactly for this: one producer, one consumer, across different cores, with built-in thread safety.