[Bug 780044] Audio stalls receiving Opus over RTP in a Raspberry Pi 3

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=780044

--- Comment #1 from Adrian Perez <aperez at igalia.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.