Audio stalls receiving Opus over RTP in a Raspberry Pi 3
Submitted by Adrián Pérez de Castro @aperezdc
Link to original bug (#780044)
Description
I have been able to consistently reproduce this issue, which has been
reported before in the mailing list:
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.
Version: 1.10.4