ESP32-audioI2S

ESP32-audioI2S copied to clipboard

I have the input buffer set to 64 kB which is almost 1.5 seconds for 320kbps radios. The ESP32 CPU is set to 240MHz. Still, some radios stutter badly, the stuttering is with a frequency of about 3-4 times a second. I have an intuition that this may be directly related to the output buffer size of 32 kB (8 * 1024 samples) which is about 0.2 seconds - this could show poor input buffer usage. It absolutely doesn't matter if the input buffer is 16kB or 64kB, the result is same. It could also be possible that the ESP32 isn't capable of decoding that particular stream in realtime.

Here's the stream aadress in question, on my PC it plays fine: http://smoothjazz.cdnstream1.com/2585_320.mp3

I also have a few 320K streams that don't run smoothly. The cause seems to be the WiFi client. Less data is supplied than is required and the buffer is not filled well.

I've been testing a lot of different streams lately and I see skipping "Slow Stream, Dropouts Possible" errors on just about all 320kb streams, and a lot of times HTTPS secure url's cause skipping when playing at 128K-196K-200K streams but when I remove the S from HTTPs and instead use HTTP it does not try to create a Secure session and runs without any skipping.

Overall the Web Radio code runs perfectly. I can leave it running for 12 hours straight on one stream without any issues.

The WiFiClient could be replaced by AsyncTCP. Unfortunately, it is not (yet?) part of the Arduino package. Another possibility is to change the sdkconfig regarding the data throughput, there are some suggestions on the net and then to recompile the IDF. There is a description here: https://github.com/espressif/arduino-esp32/issues/4529

The WiFiClient could be replaced by AsyncTCP. Unfortunately, it is not (yet?) part of the Arduino package. Another possibility is to change the sdkconfig regarding the data throughput, there are some suggestions on the net and then to recompile the IDF. There is a description here: espressif/arduino-esp32#4529

I looked into the possibility of recompiling the IDF. I witnessed that a lot has changed since the OG post. The configuration files have changed locations, have split up and a lot of configurable options have changed names or have been removed somehow. I followed the instructions as best as I could and managed to recompile the IDF. After replacing the sdk folder in my PlatformIO directory I tried to recompile my ESP32 software. This was however hopeless because the linker returned me ton of missing symbol errors and I decided to put the "IDF hack" on hold for now.

If someone has already done the "hack" I'd be glad if they provide a download link for the patched IDF.

I tested the input buffer with known working radios. I started the radio and then unplugged my router. The radio continued playing for a good second or so (I have 64kB buffer, ~320kbps radio). That concludes that the input buffer of this library is indeed working well and the problem must be related to the IDF itself. :)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Update 12.02.2023: I managed to build the Arduino Core for ESP32 as per instructions on Espressif website. Before compiling i changed the settings mentioned in https://github.com/espressif/arduino-esp32/issues/4529#issuecomment-746219537 using menuconfig. I should also mention that all the recompilation was done under WSL Ubuntu 20.04. When compiled i replaced the whole sdk folder in the PlatformIOs directory. At first I got compile errors about CONFIG_ESP_WIFI_ESPNOW_MAX_ENCRYPT_NUM being not defined. I observed that this line exists only in the header file esp_wifi.h located in sdk\esp32\include\esp_wifi\include originating from the recompiled Arduino Core directory but not the PlatformIOs original:

After deleting the line I received linking errors about mbed_tls functions missing but managed to link successfully when I provided the original PlatformIO version of it (which was much bigger). So in total, only one header

The verdict: After all the modifications I managed to successfully recompile my internet radio application but with no avail. :/ Some radios with high latency and high bitrate still stutter badly. So still, no success increasing the internal WiFi buffer sizes. :(

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

With these settings https://github.com/schreibfaul1/ESP32-audioI2S/tree/master/examples/Better_WiFi_throughput it is possible to play http://smoothjazz.cdnstream1.com/2585_320.mp3 smoothly.

With these settings https://github.com/schreibfaul1/ESP32-audioI2S/tree/master/examples/Better_WiFi_throughput it is possible to play http://smoothjazz.cdnstream1.com/2585_320.mp3 smoothly.

This is awesome! This will be useful in my project.

With these settings https://github.com/schreibfaul1/ESP32-audioI2S/tree/master/examples/Better_WiFi_throughput it is possible to play http://smoothjazz.cdnstream1.com/2585_320.mp3 smoothly.

I tested your suggestions, and to my surprise - it all works flawlessly on my ESP32-S3! 🥳

Thank you so much for your efforts! 🥇