Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gst-plugins-base gst-plugins-base
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 641
    • Issues 641
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 80
    • Merge requests 80
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gst-plugins-basegst-plugins-base
  • Issues
  • #348
Closed
Open
Issue created Mar 14, 2017 by Bugzilla Migration User@bugzilla-migration

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:

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.

Version: 1.10.4

Assignee
Assign to
Time tracking