Package: pipewire
Version: 1.6.8-1
Followup-For: Bug #1093473
I'm hitting what looks like the same bug on a separate system (Debian
testing/trixie, pipewire 1.6.8-1, wireplumber 0.5.15), reproduced both
on the current version and on the pre-upgrade 1.6.7-1 (same behavior
on both, so it's not a regression tied to a specific pipewire point
release on my end).
Symptoms match this report closely:
- Video freezes on/near the first frame (no audio at all) in every
browser tested (Chrome, Opera, Librewolf/Firefox), and even on a
plain non-YouTube <video> test page (w3.org test page, no
YouTube-specific code involved) - so this isn't specific to a
YouTube/Chrome-only code path.
- Browser-internal diagnostics (Chrome's chrome://media-internals,
Firefox's MOZ_LOG PlatformDecoderModule/MediaDecoder) show decode
and buffering both healthy the whole time; the shared audio-driven
playback clock simply never advances past the first few frames.
- `systemctl --user restart pipewire` alone (wireplumber and
pipewire-pulse do not need to be restarted too) reliably un-freezes
the *current* playback attempt, every time. It is not a permanent
fix - starting a new video/stream re-triggers the freeze until the
service is restarted again.
Additional diagnosis on my system that may help narrow this down:
1. `pactl list sinks` during a freeze shows the active output sink
(a USB headset, HyperX Cloud Flight S) reporting `State: SUSPENDED`
at the exact same time `pactl list sink-inputs` shows the browser's
stream attached to that sink as `Corked: no`, full volume, format
negotiated. So the client-side stream looks fully healthy/active,
but the sink it's attached to is suspended and evidently never
resumes to actually render it.
2. Ruled out hardware/kernel/USB as the cause: `speaker-test -D hw:X,0`
(direct ALSA, bypassing PipeWire entirely) plays audio to the same
device correctly while PipeWire's sink for it is stuck SUSPENDED.
So the device and driver are fine; this is specific to
PipeWire/WirePlumber's own suspend/resume handling for the node.
3. A brand new, independent stream to the same sink (`paplay
--device=<sink> some.wav`) also fails to produce sound and also
fails to move the sink out of SUSPENDED - so it isn't specific to
the browser's already-negotiated stream; nothing can wake this sink
again once it's suspended, short of restarting the pipewire
service.
4. Tried working around it by disabling the idle-suspend for this
specific device via a WirePlumber `monitor.alsa.rules` override,
setting `session.suspend-timeout-seconds` to `0` and separately to
a large value (86400). In both cases `wpctl inspect <node-id>`
confirmed the property was correctly applied and visible on the
live node - but the sink still suspended after exactly 5 seconds
idle, which is the hardcoded default fallback in
/usr/share/wireplumber/scripts/node/suspend-node.lua
("tonumber(node.properties[\"session.suspend-timeout-seconds\"]) or 5").
This suggests that script's idle-timer is reading a different/stale
properties view than the one `monitor.alsa.rules`' `update-props`
writes to (and that `wpctl inspect` displays), i.e. the documented
per-node suspend-timeout override does not actually reach the code
path that schedules the suspend, at least not on 0.5.15. I did not
pursue disabling the suspend-node script/hook entirely (via
wireplumber.components.rules) since doing so safely would require
reproducing its full wants/provides declaration and risks disabling
unrelated policy hooks bundled with it.
Happy to provide full `pactl`/`wpctl`/`journalctl` output from a live
repro if useful - let me know what would help.
-- System Information:
Debian Release: forky/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 7.1.3+deb14-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pipewire depends on:
ii libpipewire-0.3-modules 1.6.8-1
ii pipewire-bin 1.6.8-1
ii systemd [systemd-sysusers] 261.1-3
pipewire recommends no packages.
pipewire suggests no packages.
-- no debconf information
