ary11

# Noble GNOME images ship PulseAudio and PipeWire both enabled — audio deadlocks silently **Board:** Radxa ROCK 5B+ (`rock-5b-plus`, rockchip-rk3588) **Image:** Armbian 26.2.1 stable, Ubuntu 24.04 Noble, **GNOME desktop** (prebuilt release image, not built locally — so there are no build logs) **Now running:** Armbian 26.8.3, kernel 7.1.8-edge-rockchip64 > All outputs below were captured **before** I fixed this machine. It now runs PipeWire only, so it no longer reproduces — a fresh Noble GNOME image should. The attached `armbianmonitor -u` log is a kernel/hardware inventory and does not collect userspace service state, so it won't show the conflict either; the evidence is inline below. ## Symptom Any audio through the default device hangs forever, with no error. Most people will hit this as **"YouTube won't play"** — the page loads and buffers normally but playback stays frozen at 0:00, identically in Chromium and Brave. That's because Chromium drives its media clock from the audio renderer, so a stuck audio device freezes video with no diagnostic. It sends you hunting for codec, VA-API or network faults that aren't there. ## Cause The image enables **two sound servers at once**. Both hold the ALSA control devices: ``` $ fuser -v /dev/snd/controlC0 /dev/snd/controlC1 /dev/snd/controlC2 /dev/snd/controlC0 -> PIDs: 1273 1275 (pulseaudio wireplumber) /dev/snd/controlC1 -> PIDs: 1273 1275 (pulseaudio wireplumber) /dev/snd/controlC2 -> PIDs: 1273 1275 (pulseaudio wireplumber) ``` Both were enabled in the image itself, in the same second (2026-03-01 is the build date): ``` 2026-03-01 05:59 pulseaudio.service -> /usr/lib/systemd/user/pulseaudio.service 2026-03-01 05:59 pipewire.service -> /usr/lib/systemd/user/pipewire.service ``` The GNOME package list installs PulseAudio explicitly — `config/desktop/common/environments/gnome/config_base/packages` (at tag `v25.02`, matching my image) contains `pulseaudio` and `pulseaudio-module-bluetooth`, but **no `pipewire-pulse`**. Meanwhile GNOME pulls PipeWire in transitively: `gnome-remote-desktop` → `wireplumber` → `pipewire`, both marked `AUTO`. So PulseAudio owns the pulse socket, WirePlumber independently claims the same cards, and nothing reconciles them. Sinks never leave `SUSPENDED`. ## Reproduce Boot any Noble GNOME image and check: ``` $ systemctl --user is-active pulseaudio pipewire wireplumber active active active $ dpkg -l pipewire-pulse # not installed ``` A 5-second tone blocks indefinitely through PulseAudio and through ALSA `default`, but plays fine straight to hardware: ``` $ paplay tone.wav # killed at 20s timeout, sink never left SUSPENDED $ aplay -D default tone.wav # killed at 20s timeout $ aplay -D plughw:0,0 tone.wav # 5.0s OK $ aplay -D plughw:1,0 tone.wav # 5.0s OK (hdmi0) $ aplay -D plughw:2,0 tone.wav # 5.0s OK (hdmi1) ``` Hardware and kernel drivers are fine. It's purely the dual-server conflict. ## Fix On a running system, a clean swap: ``` sudo apt install pipewire-pulse pipewire-alsa # removes pulseaudio, pulseaudio-module-bluetooth ``` Afterwards `paplay` completes in 5.1s, sinks reach `IDLE`, and video plays at real time. Bluetooth is covered by `libspa-0.2-bluetooth` (incl. aptX), which comes along. For the images, I'd suggest picking PipeWire — it's the Ubuntu 24.04 default and GNOME already pulls it in — by replacing `pulseaudio` / `pulseaudio-module-bluetooth` with `pipewire-pulse` / `pipewire-alsa` in the GNOME package list. Staying on PulseAudio instead would mean stopping WirePlumber from claiming the devices. Doing neither leaves the deadlock. **Note:** I confirmed the package list at tag `v25.02`. On current `main`, `config/desktop/` no longer exists, so this has been restructured since — worth checking whether the current equivalent still carries `pulseaudio` without `pipewire-pulse`. This isn't board-specific; it follows from the desktop package list, so any Noble GNOME image should be affected.

mar 22 2026 build. system seems to boot up, lights on, fans on at boot but no hdmi output