This happens on 2 of mny systems running Unstable.  It works fine when
playing audio, but when paused it will stop working and hang all attempts
to play audio until restarted via "systemctl --user restart pipewire.service".
This happens with mpv and with Google Chrome playing YouTube videos.  In both
cases pausing playback is enough to trigger the problem and restarting
pipewire will fix it.

It seems that what is happening is tha interrupting pipewire causes mpv to
change to Pulse for the output and then we have the issue that pipewire when
running hangs all other forms of output.  So just stopping pipewire solves the
problem.

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.