<div dir="ltr"><div><div><div><div><div><div>Hello folks,<br><br>I'm just getting to grips with this fantastic piece of software. I'm using software called Mopidy to stream music from the web to my server, and on to some clients on my home network. It produces a raw gstreamer source which I believe is S16LE format, to which I can attach whatever I want - in this case a codec, an RTP payloader and a udpsrc. I've so far tried lots of different approaches, but the configuration below is the only one that has even half-worked. MP3 compression didn't work, nor did Vorbis. Uncompressed audio kills my network.<br>
<br>I currently have it configured as follows:<br><br></div>[Mopidy output] ! capsfilter caps="audio/x-raw-int, format=S16LE, rate=48000, channels=2" ! audioconvert ! audioresample ! capsfilter caps="audio/x-raw-int, format=S16LE, rate=48000, channels=2" ! opusenc bitrate=128000 ! rtpopuspay ! udpsink host=224.0.0.50 port=5000 auto-multicast=true sync=true<br>
<br></div></div>On my client, which is a Raspberry Pi, I run the following command to listen to the stream:<br><br>gst-launch-0.10 -vvv udpsrc multicast-group=224.0.0.50 auto-multicast=true port=5000 ! capsfilter caps="application/x-rtp, media=(string)audio, clock-rate=(int)48000, payload=(int)96, encoding-name=(string)X-GST-OPUS-DRAFT-SPITTKA-00" ! gstrtpjitterbuffer latency=5000 mode="slave" drop-on-latency=true ! rtpopusdepay ! opusdec ! audioconvert ! audioresample ! capsfilter caps="audio/x-raw-int, format=S16LE, rate=48000, channels=2" ! alsasink sync=true<br>
<br>These are basically the example server and client given here - 
<a href="https://github.com/woutervanwijk/Pi-MusicBox/blob/master/filechanges/opt/musicbox/gst-rtp-opus-duplex.sh">https://github.com/woutervanwijk/Pi-MusicBox/blob/master/filechanges/opt/musicbox/gst-rtp-opus-duplex.sh</a>
 - but tweaked for backwards compatibility for gstreamer-0.10 and with the addition of a multicast address.<br><br></div>It works, but the audio is very choppy, which is obviously not fit for purpose for streaming music. I get messages on the client like this, over and over:<br>
<br>0:00:05.573348000  2564  0x17ed060 WARN         rtpjitterbuffer rtpjitterbuffer.c:458:calculate_skew: delta - skew: 0:00:01.019600000 too big, reset skew<br>0:00:06.802078000  2564  0x17ed060 WARN         rtpjitterbuffer rtpjitterbuffer.c:458:calculate_skew: delta - skew: 0:00:01.228736000 too big, reset skew<br>
0:00:07.826141000  2564  0x17ed060 WARN         rtpjitterbuffer rtpjitterbuffer.c:458:calculate_skew: delta - skew: 0:00:01.024073000 too big, reset skew<br><br>I've tried modifying the gstrtpjitterbuffer's latency value, even up to 15 seconds; I've tried adding a queue before the jitter buffer; I've tried changing sync to false on both client and server in various combinations... and nothing really changes in terms of the choppyness: the audio starts to play quite quickly but it is choppy throughout.<br>
<br></div>I think my home network is probably causing a little bit of latency, but I struggle to believe it can't cope with a single compressed audio stream. The server running Mopidy only sees about 20% load when it is streaming to the client, so I don't think it's the server either.<br>
<br></div><div>Does anyone have any advice for optimising the above configuration? Or an alternative codec to use? As I said, MP3 didn't work for me, but if others have working pipelines to share then I would happily use it. All I really want is a 192kbps audio stream, ideally also synchronised to the server's clock so I can play synchronised audio on multiple client (though I can drop this requirement if necessary).<br>
<br></div><div>Thanks for reading!<br></div></div>