Version info
- GStreamer version: 1.22.0
- PipeWire version (
pipewire --version): 1.2.4 - Distribution and distribution version (
PRETTY_NAMEfrom/etc/os-release): Raspbian GNU/Linux 12 (bookworm) - Desktop Environment: none
- Kernel version (
uname -r): 6.1.21-v8+ (Raspberry Pi 4B)
Description of Problem:
The following GStreamer pipeline works fine for a while, but randomly (could be after minutes or hours) starts increasing error count and playing back audio with many seconds of delay. The idea is to play back live RTP Opus audio from udpsrc like this:
gst-launch-1.0 --messages udpsrc address=127.0.0.1 port=22101 reuse=FALSE caps="application/x-rtp" ! rtpopusdepay ! opusdec ! audioconvert ! audioresample ! audio/x-raw, rate=48000, channels=1, format=S16LE ! level name=audio-level-monitor post-messages=TRUE interval=50000000 ! pipewiresink target-object="alsa_output.platform-fd500000_pcie-pci-0000_01_00_0-usb-0_1_4_1_1_0.analog-stereo"
The UDP source stream is not always available or it may be muted, so I’m suspecting these transitions might cause issues.
This is what pw-top shows: (see the ERR column)
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME
S 31 0 0 --- --- --- --- 0 Dummy-Driver
S 32 0 0 --- --- --- --- 0 Freewheel-Driver
S 41 0 0 --- --- --- --- 0 Midi-Bridge
S 53 0 0 --- --- --- --- 0 alsa_output.platform-bcm2835_audio.stereo-fallback
R 35 512 48000 37.6us 62.6us 0.00 0.01 0 S16LE 2 48000 alsa_output.platform-fd500000_pcie-pci-0000_01_00_0-usb-0_1_4_1_1_0.analog-stereo
R 89 0 48000 39.7us 23.2us 0.00 0.00 3531249 S16LE 1 48000 + gst-launch-1.0
R 47 512 48000 29.4us 6.2us 0.00 0.00 2 S16LE 2 48000 alsa_input.platform-fd500000_pcie-pci-0000_01_00_0-usb-0_1_4_1_1_0.analog-stereo
R 72 0 0 35.4us +++ 0.00 +++ 28 S16LE 2 96000 + gst-launch-1.0
S 45 0 0 --- --- --- --- 0 alsa_output.platform-fd500000_pcie-pci-0000_01_00_0-usb-0_1_3_3_2_1_0.analog-stereo
R 46 512 48000 26.3us 6.1us 0.00 0.00 0 S16LE 2 48000 alsa_input.platform-fd500000_pcie-pci-0000_01_00_0-usb-0_1_3_3_2_1_0.analog-stereo
R 74 0 0 --- 252.8us --- 0.02 44 S16LE 2 96000 + gst-launch-1.0
There are also some xruns visible in kernel log, but the timestamps did not match when the issue starts, so I suspect they are unrelated:
pipewire[443]: pw.node: (gst-launch-1.0-72) xrun state:0xf673b008 pending:1/1 s:166120134975884 a:166120124355812 f:166120124846497 waiting:18446744073698931544 process:490685 status:triggered (0 suppressed)
pipewire[443]: pw.node: (gst-launch-1.0-72) xrun state:0xf673b008 pending:1/1 s:167235101949149 a:167235091315098 f:167235091721064 waiting:18446744073698917565 process:405966 status:triggered (0 suppressed)
pipewire[443]: pw.node: (gst-launch-1.0-74) xrun state:0xf7040008 pending:1/1 s:168034058922160 a:168034063354039 f:168034048726922 waiting:4431879 process:18446744073694924499 status:awake (0 suppressed)
pipewire[443]: pw.node: (gst-launch-1.0-74) xrun state:0xf7040008 pending:1/1 s:168745103878672 a:168745103942190 f:168745093671037 waiting:63518 process:18446744073699280463 status:awake (0 suppressed)
Previous attempts to solve issue
I’ve had a similar problem for a number of years with pulsesink (PulseAudio) and did not get many clues on the previous gstreamer-devel list: GStreamer pipeline udpsrc randomly stops receiving UDP packets
I also opened an issue on pipewire GitLab to know if they had some ideas: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4374 → but it looks like the issue might indeed be outside of Pipewire’s plugins.
How Reproducible:
I can reproduce the issue consistently.
Steps to Reproduce:
- Start the pipeline
- Mute/stop the RTP Opus UDP stream up to 100s of times (not sure exactly when/what triggers this)
Actual Results:
Error count in pw-top starts increasing and any supplied audio is played back with a long delay (5-15 seconds).
Expected Results:
No errors in pw-top and no extra delay in audio playback.