RTP audio packets are sent as a burst, not in real-time, with rawaudioparse

wegherfe wegherfe at gmail.com
Thu Apr 27 09:28:08 UTC 2017


Hi all.

I have to implement a RTP streaming pipeline for S16LE 48KHz raw audio
content, sourced from a Unix named pipe. My pipeline is the following:

gst-launch-1.0 blocksize=1388 location=/home/wegherfe/pipe-sink ! queue !
"audio/x-unaligned-raw, format=S16LE, channels=2, rate=48000,
layout=interleaved" ! rawaudioparse use-sink-caps=true ! audiorate !
audioconvert dithering=0 noise-shaping=0 ! rtpL16pay pt=99 ! queue ! udpsink
host=192.168.1.2 port=6004

In short, the pipeline sets the named pipe as file source, raw parses it
with caps, converts to S16 BE format and encapsulates data into RTP payload.
The two queues are used to split job into 3 tasks: reading, processing,
transmitting.

In order to test the pipeline, just create the Unix named pipe (as root) and
write raw audio content into it (I have attached the sample raw audio I used
in my tests: it says "front center", taken from my Ubuntu PC:  audio.raw
<http://gstreamer-devel.966125.n4.nabble.com/file/n4682828/audio.raw>  ):

mknode /home/wegherfe/pipe-sink p
cat audio.raw > /home/wegherfe/pipe-sink

The server pipeline and test commands are run on my laptop, which is
connected to a small embedded device, working as RTP client, which has
limited buffering and processing capabilities.

The problem is the following: audio is played fluently and properly at first
invocation of cat command, but it is played with glitches and bad timing
sometimes at following invocations. Usually, the first word "front" is
eaten, cannot be heard well, while "center" is usually fine.

By running tcpdump, I noticed that, with following invocations of cat
command, UDP packets are sent as a burst and not in real-time. I think this
causes issue to my client device, which has a little buffer.

Notices:
1) if I remove rawaudioparse and use wavparse, audio is always ok:

gst-launch-1.0 filesrc location=/home/wegherfe/Front_Center.wav ! wavparse !
queue ! audioresample ! audioconvert dithering=0 noise-shaping=0 ! rtpL16pay
pt=99 ! queue ! udpsink host=192.168.1.2 port=6004

so I think the problem is in timestamps generated by rawaudioparse;

2) if I set blocksize to smaller values, the client device does not work
properly
3) queue elements seems to mitigate the issue a bit



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/RTP-audio-packets-are-sent-as-a-burst-not-in-real-time-with-rawaudioparse-tp4682828.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.


More information about the gstreamer-devel mailing list