WebRadio with 2 ESP32s via I2S streaming to an ordinary BluetoothBox via A2DP

[cvoinf]

I tried to build an Internet-Radio that uses any Bluetooth sink to play an mp3-stream on my Bluetooth-Box. Since Bluetooth and Wifi cannot be used simultaneously, I wanted to use two ESP32, one that converts the mp3-stream into a i2s-Stream and another that outputs the i2s-signals via a2dp to the bluetooth sink.

I use two NodeMCU ESP32-Development-Boards, which are connected as the following:

• 3,3V <-> 3,3V
• GND <-> GND
• GPIO14 <-> GPIO14 (BLCK)
• GPIO15 <-> GPIO15 (WS)
• GPIO22 -> GPIO32 (Data)

The first ESP32 is programmed with the following code (adapted from Phils example-program player-url-i2s)

#include "AudioTools.h"
#include "AudioTools/AudioCodecs/CodecMP3Helix.h"

const char *urls[] = {
  "http://stream.srg-ssr.ch/m/rsj/mp3_128",
  "http://stream.srg-ssr.ch/m/drs3/mp3_128",
  "http://stream.srg-ssr.ch/m/rr/mp3_128",
  "http://sunshineradio.ice.infomaniak.ch/sunshineradio-128.mp3",
  "http://streaming.swisstxt.ch/m/drsvirus/mp3_128"
};
const char *wifi = "MySSID";
const char *password = "MyPassword";

URLStream urlStream(wifi, password);
AudioSourceURL source(urlStream, urls, "audio/mp3");
I2SStream i2s;
MP3DecoderHelix decoder;
AudioPlayer player(source, i2s, decoder);

void setup() {

  // setup output
  auto cfg = i2s.defaultConfig(TX_MODE);
  cfg.i2s_format = I2S_STD_FORMAT; // or try with I2S_LSB_FORMAT
  cfg.is_master = true;
  i2s.begin(cfg);

  // setup player
  player.setVolume(0.9);
  player.begin();
}

void loop() {
  player.copy();
}

The second ESP32 is flashed with the following program (adapted from steams-i2s-a2dp):

#include "AudioTools.h"
#include "AudioTools/AudioLibs/A2DPStream.h"


I2SStream i2sStream;                            // Access I2S as stream
A2DPStream a2dpStream;                          // access A2DP as stream
StreamCopy copier(a2dpStream, i2sStream); // copy i2sStream to a2dpStream

// Arduino Setup
void setup(void) {
    
    // start bluetooth
    i2sStream.addNotifyAudioChange(a2dpStream); // a2dp is using the info from i2s
    
    auto cfgA2DP = a2dpStream.defaultConfig(TX_MODE);
    cfgA2DP.name = "NameOfMyBluetoothBox";
    
    a2dpStream.begin(cfgA2DP);

    // set intial volume
    a2dpStream.setVolume(0.6);

    // start i2s input with default configuration    
    auto cfg = i2sStream.defaultConfig(RX_MODE);
    cfg.i2s_format = I2S_STD_FORMAT; // or try with I2S_LSB_FORMAT
    cfg.is_master = false;
    i2sStream.begin(cfg);
}

// Arduino loop - copy data
void loop() {
   copier.copy();
}

Two points have been important: the first ESP has to be set as master of the i2s-stream, the second as slave ( cfg.is_master = false; ). And secondly, any debug-information via Serial does disrupt the stream.

I am using version 1.0.0 from the arduino-audio-tools library, as well as the libhelix library from Phil. The ESPs have to be flashed with partition-scheme "HugeApp".

Up to now, it works quite promising, but after the first second, every 200ms or so there is some disruption of the stream. Has anybody an idea, how to get rid of this? I suppose, it's an performance/timing-problem, but I have no idea, how to optimize the code.

[pschatzmann]

Don't use I2S to communicate audio between the 2 ESP32: I think this is just not working reliably.
I suggest that you look into SPI...

[cvoinf]

Now it works, even via i2s! The glitches are gone. According to this comment I now resample the mp3-stream to 44100 kHz. So the program for the first ESP32 now looks like this:

#include "AudioTools.h"
#include "AudioTools/AudioCodecs/CodecMP3Helix.h"
#define SAMPLE_RATE     44100
#define CHANNEL_COUNT   2
#define BITS_PER_SAMPLE 16

const char *wifi = "MySSID";
const char *password = "MyPassword";

URLStream urlStream(wifi, password);
AudioInfo finalAudoPropsInfo(SAMPLE_RATE, CHANNEL_COUNT, BITS_PER_SAMPLE);

I2SStream i2s;
ResampleStream resample(i2s);                            // resample to guarantee finalAudoPropsInfo at I2S output
EncodedAudioStream dec(&resample, new MP3DecoderHelix());   // Decoding stream
StreamCopy copier(dec, urlStream);                             // copy url to decoder


void setup() {
  Serial.begin(115200);
  while(!Serial);
  AudioLogger::instance().begin(Serial, AudioLogger::Warning );
  
  // setup output
  auto cfg = i2s.defaultConfig(TX_MODE);
  cfg.copyFrom(finalAudoPropsInfo);
  cfg.i2s_format = I2S_STD_FORMAT;
  //cfg.buffer_size=1024;
  //cfg.buffer_count=32;
  cfg.is_master = true;
  i2s.begin(cfg);
    
  auto rsConfig = resample.defaultConfig();
  rsConfig.copyFrom(finalAudoPropsInfo);
  resample.begin(rsConfig);

  //urlStream.begin("http://wdr-diemaus-live.icecastssl.wdr.de/wdr/diemaus/live/mp3/128/stream.mp3", "audio/mp3");
  urlStream.begin("http://stream.srg-ssr.ch/m/rsj/mp3_128", "audio/mp3"); 
  
  // make sure that resample is updated
  dec.addNotifyAudioChange(resample);
  
  // setup I2S based on sampling rate provided by resample
  dec.begin();
}

void loop() {
  copier.copy();
}

Only after a minute or so the wdr-maus-stream jumps, I don't know why. But the Jazz-Radio-stream runs perfectly.

I assume resampling costs even more cpu power. Since the above program works now, cpu power seems not the problem, but different sample-rates of server and master of the i2s-routine of the first approach.

[pschatzmann]

Cool, you can savely remove the addNotifyAudioChange command.
This is done automatically along the chain: so dec informs resample which informs i2s...

[cvoinf]

I was wondering if it wouldn't be better to let the second ESP32 do the resampling: If I want to build an advanced radio, the first ESP32 will have to do much more work (Display, nextSender-button, volume, ...), and the second ESP32 is not exhausted anyway.

So I kept the first sketch for the first ESP32 and changed the program for the second one. It works as well:

#include "AudioTools.h"
#include "AudioTools/AudioLibs/A2DPStream.h"

I2SStream i2sStream;                            // Access I2S as stream
A2DPStream a2dpStream;  
ResampleStream resample(a2dpStream);
StreamCopy copier(resample, i2sStream, 4048*4); // copy i2sStream to a2dpStream

// Arduino Setup
void setup(void) {
   Serial.begin(115200);
   while(!Serial);
   AudioLogger::instance().begin(Serial, AudioLogger::Warning);
    
    // start i2s input 
    auto cfg = i2sStream.defaultConfig(RX_MODE);
    cfg.i2s_format = I2S_STD_FORMAT; 
    cfg.buffer_size=1024*8;
    cfg.buffer_count=64;
    cfg.sample_rate = 48000;
    cfg.is_master = false;
    i2sStream.begin(cfg);


  auto rsConfig = resample.defaultConfig();
  rsConfig.step_size = 48000.0/44100;
  resample.begin(rsConfig);

  auto cfgA2DP = a2dpStream.defaultConfig(TX_MODE);
    cfgA2DP.name = "NameOfMyBluetoothBox";
      // set intial volume
    a2dpStream.setVolume(0.8);

    a2dpStream.begin(cfgA2DP);
}

// Arduino loop - copy data
void loop() {
   copier.copy();
}

Well, there is a little disadvantage: In case of restarting the first ESP32, the sound has glitches again. I think, this is due to the fact that the ESPs then are not synchronized correctly any more. Perhaps this time I need a kind of addNotifyAudioChange-command?

But I think the advantage is, that the i2s-stream with 48kHz is more compatible to other projects: I nearly managed to run the second ESP32 as i2s->bluetooth-sink for kaRadio with this approach...

[cvoinf]

I am wondering if the pitch is changed while resampling? I think I need an oscilloscope to verify...

[cvoinf]

It now works with kaRadio: I previously forgot to flash the GPIO-Configuration (standard_adb.bin). Since I have linux, I had to flash it via esptool:

esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 460800 --before default_reset --after hard_reset write_flash --erase-all -u --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader.bin 0x10000 KaRadio32.bin 0x8000 partitions.bin 0x3a2000 standard_adb.bin

The kaRadio-ESP32 has to be connected to the second ESP32 flashed with this program according to the following table:

kaRadio-ESP	i2s->a2dp-ESP
GPIO22 DOut	GPIO32 DIn
GPIO25 WS	GPIO15 WS
GPIO26 BLCK	GPIO14 BLCK
5V	5V
GND	GND

The only little remaining problem: if the kaRadio-stream is restarted (for example by changing the radio-station), the stream is steadily interrupted by small glitches. If the second ESP32 is restarted, the glitches are gone....

[bpavlov]

Hello! I was trying to create a web radio that streams audio directly to a Bluetooth speaker using A2DP.
Initially, I focused on reading an audio stream from the web and outputting it to the ESP32's pins. By probing with headphones, I confirmed that the audio was playing. Then, I managed to connect the ESP32 to a Bluetooth speaker and send some noise to it. Now, it seems like it should be straightforward to combine these functions, right?

I started by trying to accomplish this with a single ESP32. After numerous attempts, I learned several things. While some might be obvious to experienced developers, I'll document them here for anyone searching for a solution:

Hardware Considerations:

1. Bluetooth Types: Bluetooth, BLE, and Bluetooth Classic are three different animals.
2. RTFM: "ESP32 Dev Board" isn’t enough. Always read the datasheet and specifications for details. Check for PSRAM. Save your day.
   3 Antenna Limitations: My ESP32 boards have a single RF antenna, which can either be used for Bluetooth or WiFi but not both simultaneously.
3. PSRAM Requirement: For WiFi and Bluetooth Classic to coexist, your ESP32 board needs PSRAM. It is stated officially by Espressif
4. Common Grounding: Ensure a common GND reference to reduce noise in communications.

Software Considerations:

1. ESP-IDF Installation: Espressif’s documentation recommends using the VS Code extension for ESP-IDF on Windows and Mac. Do a manual installation thank me later.
2. Be careful with Documentation: Some links on Espressif’s website are outdated or incorrect. You might find a README.md file on GitHub, but even this can sometimes be outdated.
3. Menu Configuration: many times you have to run idf.py menuconfig and do some settings that are not written in the documentation of the project. This could be very frustrating for newbies.
4. Outdated Web Radio Projects: Most web radio ESP32 projects are outdated, particularly those using ESP-IDF. Many still use .mk files instead of CMakeLists.txt, making them hard to compile. In my experience, recreating them is faster than trying to migrate them.
5. ESP-IDF: ESP-IDF is not beginner-friendly.
6. ESPHome Limitations: ESPHome is easy to use but does not support Bluetooth Classic and of course A2DP.
7. Protocols: I learned about the I2S and SPI protocols. Although I tried SPI communication, it was "noisy" even with standard ESP-IDF examples.
8. APP size limits: You can increase your app size at the cost of losing OTA update capabilities.

After all these struggles I am glad that I found this discussion.
Thanks to both of you @cvoinf and @pschatzmann I was able to implement/recreate this project.
It was amazing to find that by just installing several libraries (provided by @pschatzmann) and by coping only two files (provided by @cvoinf) now I have my Jaz radio up and running.

Sorry for hijacking the discussion and for the long post. I have one question regarding two things:

1. What is the benefit of using KaRadio over simple implementation without it?
2. What about adding SSD1306 display? Will using I2C in this project introduce some issues?

[pschatzmann]

Thanks for your post: what was the reason why you went the difficult IDF route instead of using Arduino ?

[cvoinf]

Your question implies the answer: KaRadio32 has already implemented the control of the SSD1306 display (and other features).

[bpavlov]

TLDR; I found ESP-IDF first and I was not able to find Arduino implementation (at first). But after failing a couple of times I am here.

In the past, I did some basic projects using Arduino. I also "re-use" some bigger projects. After that I start making my home smart. I discovered Shelly products (IoT devices with a lot of capabilities based on ESP32). I was trying to "re-implement" those capabilities (by searching for already implemented solutions). Then I discovered Home Assistant and ESPHome. So I take a step back and reimplement all those projects using ESPHome. I was really easy.
The main benefits that I got from this were:

1. Centralized place for source code, deploying, debugging and managing devices
2. No IDE/IDF/SDK/Library installation
3. You can use different platforms via configuration (ex. Arduino, ESP-IDF, etc.)
4. Good and easy-to-follow documentation
5. OTA updates
6. WiFI debugging
7. Integration with ALL my other smart/IoT devices
8. Voice assistant control - Local/Online Sattelite (ESPHome with optional integration to OpenAI or even your own LLM), Alexa, Google Assistant
9. No programming skills were required (most of the time). You just define one .yaml file.
   And many more...

So having this powerful tool sky was the limit. I make most of my dump devices smart. I was able to use BLE of my brush to remind me if I didn't brush my teeth long enough. I did so many interesting projects with ESP32 and sensors so I can even recall all of them. I even created my smart home voice assistant.

So back to the point. The missing part of ESPHome is Bluetooth Classic support (it supports BLE and Bluetooth Proxy though). I believe the main reason for this is WiFi and Bluetooth coexistence.

I want to make one dump RF car smart and control it with a PlayStation 4 Dual Shock joystick. As I mentioned before this was not possible to implement with ESPHome. I found Arduino library. And with some tweaks I did it. (And as I saw earlier today this library is not compatible with Bluetooth libraries here).
After that, I wanted to implement more Bluetooth Classic projects. So streaming music to Bluetooth speaker was a good candidate. Especially when I previously was able to connect to a proprietary PS4 joystick. But because I do not have ESP32 with a storage card I thought it would be a good idea to check if I can get audio from the web. So the plan was to get mp3 over HTTP and stream it via Bluetooth Classic to Bluetooth speaker. I tried so many implementations of this without luck. I wasn't able to just build some of them. They were outdated. I was hitting the coexisting limitations without knowing it. I even bought a new ESP32s (assuming mine are not powerful enough). By the time they arrived, I already knew the need of PSRAM for coexistence to work. It was described on the ESP-IDF official web page. This was a game-changer. By this time I was thinking that I had done something wrong. Realising this I was thinking about another solution - using two esp32. So I divided the problem into two smaller ones.

1. Get the audio stream over HTTP
2. Stream it to a speaker over Bluetooth
3. Find a way for both to communicate

For 1. I found a YouTube video doing this in 5 minutes. Unfortunately, the code was on an older version of ESP-IDF. I was too lazy to downgrade the version of ESP-IDF so I re-implemented it using the newest ESP-IDF.

And maybe here is the answer to your question. Having (1) implemented in ESP-IDF it was natural to continue with ESP-IDF path. Then I implemented (2). But for (3) I decided to use SPI communication as according to ChatGPT this was the best solution. So after trying over-complicated examples for SPI communication (with handshake pin) and getting a lot of noise in the serial bus, I asked ChatGPT and he linked me to here. At first, I was not able to find this discussion I thought it was wrong. But I am glad I am here.

I know I cannot contribute much to this (knowledge limitations) but here are my findings:

1. I was able to "recreate" ESP32 1 (sender) via ESPHome.
2. I was not able to "recreate" ESP32 due ESPHome limitations for A2DP support
3. I was able to add i2c SSD1306 OLED display to ESP32 1 (sender). There are some glitches (in sound) but I need to do more tests to find the root cause. I am using DuPont wires and I do not believe them. I think that ESPHome does not support threads. Not sure about Arduino. IDF-ESP support it. Some users suggest using different thread for OLED updates. (I didn't know that ESP32 support threads)
4. I was able to display the current date, time, temperature, humidity, IoT sensor data (not connected directly to this device) and arbitrary texts. URLs for the stations could be extracted outside of the code as configuration. (thanks to Home Assistant <-> ESPHome integration)
5. I used Arduino as a platform in ESPHome config. Here is the output result of the building with OLED support:

RAM:   [=         ]  13.4% (used 44060 bytes from 327680 bytes)
Flash: [=======   ]  70.3% (used 1289585 bytes from 1835008 bytes)
Building .pioenvs/esp32-display/firmware.bin

This post is already painfully long. So I will stop here. Do not hesitate to correct me, commend or ask.

[bpavlov]

Your question implies the answer: KaRadio32 has already implemented the control of the SSD1306 display (and other features).

And that repo also represent my struggles. It takes me several hours and 10GB disk space just to change the pin layout. Maybe there is huge knowledge gap but ESP-IDF projects are over engineered at best.

NB: When OLED is enabled I experienced some cracking noise. Performance is better than ESPhome and HA which was expected.
Some mp3 streams (64/128) are not playable.

Recreating KaRadio in HA is doable to some point.

Now I discovered this: https://github.com/e2002/yoradio I will give it a try.

Thank you for pointing KaRadio and pin connections. It helped me a lot!

[cvoinf]

Perhaps you could verify if the sampling rate of the non-working mp3-streams are 48kHz? This is easliy done with vlc.

My assumption is that they have other sampling rates, so that you have to change the resampling factor accordingly.

And concerning the cracking noise, could you test if a restart of the second ESP32 could solve that problem? Maybe this is a synchronization problem.
In both cases we had to think of changing the code for the second ESP32 to intelligently adapt to the stream.

[bpavlov]

I tried both (128mHz and 48mHz) versions from here.

I found the issues for one particular stream:
KaRadio reads the metadata of the stream. When there are special characters (Cyrillic for example) this breaks the program on ESP32 (1).

Today I burned yoRadio on first ESP32. So I was able to play the same (previously broken 128kHz) stream. I also matched the I2S pins of the two ESPs so I do not need to remember them.

About cracking noise:

1. ESPHome: Cracking noises are on every tick when the display is updated. I believe this is an issue with I2C and I2S working simultaneously. So as of now maybe ESPHome is not a good solution.
2. KaRadio; Cracking noises are without a pattern. When I tested it I was using DuPonts which can be loose sometimes.
3. yoRadio: The same situation as KaRadio but I got a 30-second uninterrupted stream (I can provide video). And then it starts cracking without moving anything or touching anything.

For 3) and 4) most of the time this stream works without cracking. Or maybe I can't hear it because of the type of music.

Since you did not experience those I started to believe that this is a hardware issue. So I tried those things:

1. Connecting/reconnecting different power supplies, USB ports, USB cables. I removed the waiting for a debug serial on ESP32 (2) to be able to connect it to the power supply.
2. All starting/restarting possible scenarios.
3. I even solder cables directly to ESP pins
   

The cracking noise is still there and I cannot find the root cause. The stream that I am testing on is 128mHz.

[bpavlov]

After writing this post I tried one more time. This time there was no audio input (after trying every booting sequence cable and power supply).

One of the pins was not making good contact although soldered in place.
So you can ignore the cracking issues from previous posts. It was a hardware (and behind the keyboard device) issue.

Maybe we can proceed with improving device (2).