Choppy audio with Opus audio via RTP multicast

[Sean Leavey]

Hello folks,

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.

I currently have it configured as follows:

[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

On my client, which is a Raspberry Pi, I run the following command to
listen to the stream:

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

These are basically the example server and client given here -
https://github.com/woutervanwijk/Pi-MusicBox/blob/master/filechanges/opt/musicbox/gst-rtp-opus-duplex.sh-
but tweaked for backwards compatibility for gstreamer-0.10 and with
the
addition of a multicast address.

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:

0:00:05.573348000  2564  0x17ed060 WARN         rtpjitterbuffer
rtpjitterbuffer.c:458:calculate_skew: delta - skew: 0:00:01.019600000 too
big, reset skew
0:00:06.802078000  2564  0x17ed060 WARN         rtpjitterbuffer
rtpjitterbuffer.c:458:calculate_skew: delta - skew: 0:00:01.228736000 too
big, reset skew
0:00:07.826141000  2564  0x17ed060 WARN         rtpjitterbuffer
rtpjitterbuffer.c:458:calculate_skew: delta - skew: 0:00:01.024073000 too
big, reset skew

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.

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.

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).

Thanks for reading!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140512/8cb0c11b/attachment-0001.html>