GNOME Bugzilla – Bug 780044
Audio stalls receiving Opus over RTP in a Raspberry Pi 3
Last modified: 2018-11-03 11:55:50 UTC
I have been able to consistently reproduce this issue, which has been reported before in the mailing list: http://gstreamer-devel.966125.n4.nabble.com/Audio-stalling-when-using-Opus-to-send-audio-to-Raspberry-Pi-3-tt4681213.html To reproduce, launch the commands suggested in the email above. A recap: - In a computer: gst-launch-1.0 audiotestsrc ! opusenc ! rtpopuspay ! udpsink host=<IP of RPi> port=5555 - In the Raspberry Pi: GST_DEBUG=4 gst-launch-1.0 udpsrc port=5555 caps="application/x-rtp" ! rtpopusdepay ! opusdec ! audioconvert ! pulsesink Now, in order to reproduce the issue very easily, repeteadly disable and re-enable the network interface of the *computer*. After 3-4 cycles, the warning messages start to appear: 0:00:46.587793889 355 0x712014c0 WARN pulse pulsesink.c:702:gst_pulsering_stream_underflow_cb:<pulsesink0> Got underflow 0:00:54.536071281 355 0x712014c0 WARN pulse pulsesink.c:702:gst_pulsering_stream_underflow_cb:<pulsesink0> Got underflow 0:01:15.323500284 355 0x65a260 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:<pulsesink0> correct clock skew -0:00:00.021637386 < -+0:00:00.020000000 0:01:15.463535544 355 0x65a260 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:<pulsesink0> correct clock skew -0:00:00.024740252 < -+0:00:00.020000000 0:01:15.563458930 355 0x65a260 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:<pulsesink0> correct clock skew -0:00:00.027595592 < -+0:00:00.020000000 ... After making a few more tests, I could find out that the issue is *not* trigger in any of the following cases (i.e. they work fine): - Sending audio in the other direction (RPi → PC) and fiddling with the network interface of the RPi. - Sending audio from a PC to another PC. - Using “alsasink” in the RPi.
As suggested by Sebastian in #gstreamer, I have tried the same pipelines again adding a “rtpjitterbuffer” element before “rtpopusdepay” on the receiving end. After turning off and on again the NIC a few times, the sound gets stalled and never comes back again when the network is up and running. The part of the log when the audio gets stalled still looks similar (though it's not exactly the same): 0:00:02.559050520 404 0xdd3630 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:<pulsesink0> correct clock skew -0:00:00.020193871 < -+0:00:00.020000000 0:00:04.382092707 404 0xdd3630 WARN audiobasesink gstaudiobasesink.c:1484:gst_audio_base_sink_skew_slaving:<pulsesink0> correct clock skew +0:00:00.020023748 > +0:00:00.020000000 0:00:05.448722706 404 0xdd3630 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:<pulsesink0> Unexpected discontinuity in audio timestamps of +0:00:00.040000000, resyncing 0:00:29.832140301 404 0x70b01380 WARN pulse pulsesink.c:702:gst_pulsering_stream_underflow_cb:<pulsesink0> Got underflow 0:00:33.296620873 404 0xdd3660 INFO rtpjitterbuffer gstrtpjitterbuffer.c:2486:calculate_expected:<rtpjitterbuffer0> lost packets (185, #24375->#24559) duration too large 0:00:03.720000207 > 0:00:00.200000000, consider 175 lost (0:00:03.500000185) 0:00:38.914460923 404 0x70b01380 WARN pulse pulsesink.c:702:gst_pulsering_stream_underflow_cb:<pulsesink0> Got underflow 0:00:42.596592067 404 0xdd3660 INFO rtpjitterbuffer gstrtpjitterbuffer.c:2486:calculate_expected:<rtpjitterbuffer0> lost packets (197, #24828->#25024) duration too large 0:00:03.960000042 > 0:00:00.200000000, consider 187 lost (0:00:03.740000000) 0:00:44.717180712 404 0xdd3630 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:<pulsesink0> correct clock skew -0:00:00.023498510 < -+0:00:00.020000000 ... Modifying the size of the buffer (for “rtpjitterbuffer”) does not make the situation any better — audio still ends up stalled.
Created attachment 348823 [details] Log output of the client side, with rtpjitterbuffer added
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/348.