Created attachment 350526 [details]
Sample audio file used to reproduce the issue

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: <nabble_a href="audio.raw">audio.raw</nabble_a>):

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