Skip to content

Communication

Jump to bottom
Phil Schatzmann edited this page Apr 22, 2025 · 28 revisions

You can transmit audio information over a wire or (e.g. if you have an ESP32) wirelessly. It is important that you make sure that the transmitted amount of audio data is below the transmission capacity of the medium (e.g. by limiting the channels, the sample rate or the bits per sample). Otherwise you run into buffer underflows and the playback of audio is breaking up.

For a sample rate of 44100 with 2 channels and 16 bit data you need to be able to transmit faster then 44100 * 2 channels * 2 bytes = 176400 bytes per second. Using a serial communication with a stop bit this gives 176400 * 9 = 1'587'600 bps!

Therefore should also consider to use one of the many supported CODECs to decrease the transmitted amount of data!

I can recommend the following codecs for this purpuse:

Buffer Overflows/Buffer Underflows

Please note that some communication methods or protocols do not offer any flow control (e.g. UDP or Serial):

  • If the data source is providing the data at the correct rate (e.g. I2S, Analog) you only need to make sure that this rate is below the capacity of the line (as described above).
  • If the data source is not limited to the audio rate (e.g. Files, URL, Serial...) you need to make sure that your receiving side can process the data faster then the sending side to prevent any buffer overflow and lost data. This is e.g. a problem when you want to play back the data. You have two options to handle this:
    • Add a Throttle on the sender side to limit the sending speed to the output speed on the receiving side. This is only possible if you deal with PCM data. This is no option if the data has a undefined or variable compression ratio (e.g. MP3).
    • Use a Protocol that provides flow control (TCP/IP, Serial with CTS/RTS) or implement your own flow control logic to block the sending of data if the receive buffer is full: This prevents lost data from buffer overflows!

Network

Networking is considered to be part of the core functionality of this library. In the AudioConfig.h you can define the networking functionality that should be activated

#define USE_ETHERNET  // Use the Arduino Ethernet library (e.g. for the Ethernet Shield)
#define USE_WIFI      // Use the (ESP) WiFi library
#define USE_AUDIO_SERVER // Activate the Server functionality
#define USE_URL_ARDUINO  // Activate the URLStream

Protocols

I am currently providing examples for:

HTTP Client

The following classes can be used as HTTP Client and implement the AbstractURLStream API.

  • URLStream: Supports HTTP GET, POST, PUT and DELETE
  • ICYStream: Supports the ICY protocol
  • URLStreamBuffered: Using buffer that is filled by a task
  • ICYStreamBuffered: Using buffer that is filled by a task

The above classes are dependent on the Arduino Networking API. I thought that it would be cool to have this functionality also working for the ESP32 outside of Arduino. The following implementations just depend on the IDF:

  • URLStreamESP32
  • ICYStreamESP32
  • URLStreamBufferedESP32
  • ICYStreamBufferedESP32

Further information can be found in my blogs...

Clone this wiki locally