Feature Request: RTP Multicast source to I2C with Receiver Report

[elshnkhll]

Hi,
Please add an example of RTP Multicast source to I2C with (Receiver Report).
Regards.

[stefan-oskamp]

I was trying to use the UDP example to output an RTP stream to I2S until I realised that the UDPStream does not decode RTP but instead plays the RTP header.
@pschatzmann, did you consider implementing an RTPStream class? Or can you provide some guidance as to how to add one.
An RTP Receiver would be great for playing audio from Linux using a Pipewire RTP sink.
Multicast, as requested by @elshnkhll, might also be nice, but I believe it will be difficult to synchronise multiple receivers because packets are sent to each receiver individually by the access point as opposed to clients connected via Ethernet. And for streaming to a single receiver, we can, of course, use unicast.

[stefan-oskamp]

I copied UDPStream.h to RTPStream.h, renamed the class, and changed the available() method to skip the RTP header:

  int available() override {
    int size = WiFiUDP::available();
    // if the current package is used up we prvide the info for the next
    while (size == 0) {
      size = parsePacket();
      if (size > 12) {
        // Read and ignore the RTP header (12 bytes)
        uint8_t header[12];
        int bytes_read = WiFiUDP::readBytes(header, sizeof(header));
        size -= bytes_read;
      }
    }
    return size;
  }

I connected the ESP32 with the PCM5102A I2S board to my Cyrus amp. There was initially a lot of noise. That went away when I used a USB power supply instead of a computer USB port. The sound is excellent, but there are still a few drop-outs (about one every couple of seconds, sounds like a scratch in a record). I also tried streaming mono audio (48000/1/16) to a Tivoli Audio radio. That had less drop-outs and sounded great.

My idea was to replace the Raspi that runs PulseAudio and is currently connected to the Cyrus amp. I might have to look for a controller with an Ethernet port.

The definition of the Pipewire RTP sink in ~/.config/pipewire/rtp-sink.conf is:

context.modules = [
 {   name = libpipewire-module-rtp-sink
     args = {
         destination.ip = "192.168.1.193"
         destination.port = 7000
         net.mtu = 1068
         net.ttl = 1
         net.loop = false
         sess.name = "PipeWire RTP stream"
         sess.media = "audio"
         audio.format = "S16LE"
         audio.rate = 48000
         audio.channels = 2
         audio.position = [ FL FR ]
         stream.props = {
            media.class = Audio/Sink
            node.name = "rtp-sink"
            node.description = "RTP"
         }
     }
}
]

[pschatzmann]

So, what's wrong with the existing rtsp example ?

I also propose to have a look at snapcast