[Pkg-utopia-maintainers] Bug#1093473: pipewire: Just started with pipewire 1.6.8-1 / wireplumber 0.5.15

[Robert J. Clark]

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