rtpjitterbuffer breaks my pipeline

[mark.wattier at eqware.net]

I am trying to set up an audio pipeline, going over udp over wifi, with as consistent ( and hopefully minimal ) latency as possible. The goal is a constant 40ms latency. To that end I have specified a buffer time in alsasink, and added rtpjitterbuffer to limit the maximum latency, preferring short bits of silence over latency jitter. My audio source is over i2s, playng a WAV file with 1ms bursts of sine wave every 100ms, so I can measure the total latency on a scope.

Here is the pipeline:

gst-launch-1.0 -v alsasrc ! \
 audio/x-raw,format=S16LE,layout=interleaved,rate=8000,channels=1 ! \
 audioconvert ! \
 rtpL16pay ! \
 udpsink host=192.168.43.1 port=5000

gst-launch-1.0 -v udpsrc port=5000 buffer-size=1000 ! \
 "application/x-rtp, media=(string)audio, clock-rate=(int)16000, encoding-name=(string)L16" ! \
 rtpjitterbuffer mode=0 do-lost=true latency=28 ! rtpL16depay ! \
 audio/x-raw,format=S16BE,layout=interleaved,rate=16000,channels=1 ! \
 audioconvert ! \
 audio/x-raw,format=S32LE,layout=interleaved,rate=16000,channels=1 ! \
 alsasink sync=true buffer-time=40000


Without the rtpjitterbuffer, I get audio through, with latency varying from 18ms to 60ms or more. With rtpjitterbuffer, I get no output.

I added a debug option to the second pipeline, along with a few custom calls to GST_DEBUG_OBJECT, to isolate the problem, and I see that the buffers are getting dropped in alsasink:

GST_CLOCK gstclock.c:1187:gst_clock_get_calibration:<GstAudioSinkClock>^[[00m CUSTOM rate_num 0:00:00.000000001, rate_denom 0:00:00.000000001external_calibration 0:05:40.367852706internal_calibration 0:00:00.000000000
GST_CLOCK gstclock.c:1049:gst_clock_get_internal_time:<GstSystemClock>^[[00m internal time 0:05:40.403407831
GST_CLOCK gstclock.c:1094:gst_clock_get_time:<GstSystemClock>^[[00m adjusted time 0:05:40.403407831
audiobasesink gstaudiobasesink.c:545:gst_audio_base_sink_get_time:<alsasink0>^[[00m processed samples: raw 1120, delay 544, real 576, time 0:00:00.036000000
audioclock gstaudioclock.c:200:gst_audio_clock_get_time:<GstAudioSinkClock>^[[00m result 0:00:00.036000000, last_time 0:00:00.000000000
audiobasesink gstaudiobasesink.c:1439:gst_audio_base_sink_skew_slaving:<alsasink0>^[[00m internal 0:00:00.036000000 external 0:05:40.403407831 cinternal 0:00:00.000000000 cexternal 0:05:40.367852706
audiobasesink gstaudiobasesink.c:1460:gst_audio_base_sink_skew_slaving:<alsasink0>^[[00m internal 0:00:00.036000000 external 0:00:00.035555125 skew +0:00:00.000444875 avg +0:00:00.001856214
audiobasesink gstaudiobasesink.c:1237:clock_convert_external:<alsasink0>^[[00m CUSTOM external: 0:05:40.265906539 cexternal 0:05:40.367852706
audiobasesink gstaudiobasesink.c:1246:clock_convert_external:<alsasink0>^[[00m CUSTOM external: 0:00:00.101946167 cexternal 0:05:40.367852706
audiobasesink gstaudiobasesink.c:1252:clock_convert_external:<alsasink0>^[[00m CUSTOM external: 0:00:00.000000000
audiobasesink gstaudiobasesink.c:1237:clock_convert_external:<alsasink0>^[[00m CUSTOM external: 0:05:40.272156539 cexternal 0:05:40.367852706
audiobasesink gstaudiobasesink.c:1246:clock_convert_external:<alsasink0>^[[00m CUSTOM external: 0:00:00.095696167 cexternal 0:05:40.367852706
audiobasesink gstaudiobasesink.c:1252:clock_convert_external:<alsasink0>^[[00m CUSTOM external: 0:00:00.000000000
audiobasesink gstaudiobasesink.c:2049:gst_audio_base_sink_render:<alsasink0>^[[00m final timestamps: start 0:00:00.000000000 - stop 0:00:00.000000000
audiobasesink gstaudiobasesink.c:2219:gst_audio_base_sink_render:<alsasink0>^[[00m dropping late sample

Without rtpjitterbuffer, I do not follow the same path through clock_convert_external, so the start and stop below are not 0, and the render function does not drop the buffer.

I suspect I am doing something wrong with latency and/or buffers, but I have tried a wide range of experiments that have not led me to a better understanding of the problem. I set the latency to 28 in rtpjitterbuffer because the reported latency of the pipeline is 12ms, and I am trying to get it to a steady 40. Setting it to 28000000 nanoseconds does not work either.

This is gstreamer 1.12.2, built in yocto and running on a beaglebone black with a wifi cape.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-embedded/attachments/20190128/2754c623/attachment.html>