# 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.

 

Funny I ran into this today, testing for a new distro installed: PipeWire 1.6.9 with WirePlumber 0.5.17 — built from Debian sid's packaging
 

Good report, and the diagnosis is right.
Two things to add: confirmation that the package list is still the cause on current main, and measurements from a Resolute (26.04) GNOME image built with the framework that avoids it.

Current main still carries it. The desktop package definitions moved from config/desktop/ into the configng desktop YAML (tools/modules/desktops/yaml/gnome.yaml). There, pulseaudio and pulseaudio-module-bluetooth sit in the GNOME definition's minimal tier package list (lines 53–54 at a97f0d2, checked today), which every tier installs. Only the trixie, forky and sid blocks add pipewire-audio/pipewire-pulse and a packages_uninstall entry for the two PulseAudio packages. The noble and resolute blocks don't, so a Noble or Resolute GNOME image built today gets the same two-server setup you found on 26.2.1. It follows from the package list, not from the board.
 

What the framework builds when the list is fixed. I build an Orange Pi 5B image with the framework (rk35xx vendor 6.1.172, Resolute, GNOME 50.1). The customize step does what you propose, plus a belt-and-braces mask:

apt-get purge -y pulseaudio pulseaudio-module-bluetooth apt-get install -y --no-install-recommends pipewire pipewire-pulse pipewire-audio pipewire-alsa \ wireplumber libspa-0.2-bluetooth alsa-ucm-conf systemctl --global mask pulseaudio.service pulseaudio.socket

Nothing pulls PulseAudio back: gnome-settings-daemon depends on pipewire-audio | pulseaudio and libspa-0.2-bluetooth | pulseaudio-module-bluetooth, so the PipeWire side satisfies both.

Your checks, run on that image:

$ systemctl --user is-active pulseaudio pipewire wireplumber pipewire-pulse inactive active active active $ dpkg -l pulseaudio | grep ^un # not installed; pipewire-pulse, pipewire-alsa installed $ fuser -v /dev/snd/controlC0 /dev/snd/controlC1 /dev/snd/controlC2 /dev/snd/controlC0: wireplumber # WirePlumber alone, on all three cards /dev/snd/controlC1: wireplumber /dev/snd/controlC2: wireplumber $ pactl info | grep 'Server Name' Server Name: PulseAudio (on PipeWire 1.6.9) # $XDG_RUNTIME_DIR/pulse/native served by pipewire-pulse $ time pw-play tone-5s.wav 5.08 s

The sink goes IDLE right after playback (and back to SUSPENDED after the normal idle timeout) instead of never leaving SUSPENDED, and Chromium/Firefox video plays at real time. Your "frozen at 0:00" description is a very good one for a stalled audio clock — it sent me down the VA-API rabbit hole too before I looked at the sound servers.

One gotcha for whoever edits the list: don't drop pulseaudio-utils along with pulseaudio. It ships pactl/paplay, both work fine against pipewire-pulse, and a surprising number of scripts and desktop helpers assume pactl exists. My first build purged it too, and I spent a while wondering where pactl had gone.

(The package-list check and the measurements above were done with help from an LLM assistant(Claude fable 5.1); the image and the numbers are from real hardware.)

Edited September 22Sep 22 by defcom5-rockchip