Part 13 ended with the installer and a promise: a ready-to-flash SD card image. This article delivers that, and the documentation that ties everything together. The articles documented each feature. Each repository ships its own README. The flash image and docs.odio.love are what turns all of that into a coherent whole.

Flash images

The installer works. curl -fsSL https://beta.odio.love/install | bash on an existing system, five minutes on x86, fifteen on a Pi 3B+. But it still assumes SSH access, a running Debian, and someone comfortable with a terminal.

odio now ships as a flashable image through Raspberry Pi Imager. Open Imager, go to Options > Content Repository > Use custom URL, enter https://beta.odio.love/odio.rpi-imager-manifest, pick your architecture (armhf or arm64), configure hostname and SSH in Imager's settings, flash, boot. Your Pi comes up with the full stack running.

Both paths produce the same result. Same packages, same services, same configuration. The image is built from the same Ansible playbook, frozen at release time. The curl installer remains for existing systems, upgrades, and non-Pi hardware.

Since the installer shipped, the feedback has been consistent, and really encouraging. Someone wrote “I have imagined such a thing for many years, and glad to see someone has finally put all the parts together.” Another: “This is the only project in the last 5 years that allowed me to recycle my FIRST Raspberry Pi 1 from 2012!!!” A French user has a stereo amplifier that shipped with Spotify Connect, but the manufacturer stopped updating it. He switched to Qobuz and the amp became a paperweight. odio is on his to-do list to bring it back to life. Exactly what I tried to avoid when I first bought my Pi B+ in 2016.

These are three different people with three different setups, but the same underlying problem: hardware that still works, abandoned by the software that was supposed to run on it. That’s what odio is for. A pair of passive speakers from the 80s, a stereo amp from 2005, a receiver your parents bought before you were born: plug a Pi with a DAC into any of them and they become an AirPlay receiver, a Spotify Connect device, a Bluetooth speaker, a multi-room endpoint. You do need a Pi and a few peripherals (a DAC, maybe a Bluetooth dongle, optical drive, cables), but all of that is widely available and easy to find second-hand for a few euros. The hardware was never the problem. The missing piece was always the software. That’s what the flash image makes accessible to anyone with an SD card reader.

Why it matters

odio was carbon-positive from its very first user: me. All the R&D, the development, the CI pipelines, the electricity, the AI-assisted coding sessions: I estimated the total carbon cost of developing odio at roughly 4 kg of CO2 (AI inference on US datacenters, GitHub Actions CI, and the marginal cost of my dev machine running on clean nuclear energy). That’s a rough estimate, and I’d welcome better data on AI inference energy costs if anyone has it.

That cost was paid back the moment I didn’t buy a commercial streamer. According to Sonos’s own environmental report (ISO 14040/14044, third-party verified), a single Era 100 represents 166 kg of CO2e over its lifetime, of which about 42 kg is manufacturing alone. My Pi B+ was already in a drawer. Every new odio user who rescues an old Pi or avoids buying a disposable streamer does the same math. The development cost is fixed and already paid. The software duplicates for free. The hardware doesn’t.

The Pi is not the only old hardware here. My NAS is from 2013. My HTPC too. My TV is from 2014. They’re all still running the latest Debian, all still doing their job. The pattern is the same every time: a low-power, specialized machine, given one clear role, and kept alive by free software. The NAS stores and serves. The HTPC keeps my 2014 TV as a functional smart TV. The Pi plays music. None of them are powerful. All of them are sufficient.

Working on this project reminded me why I fell in love with computing in the first place. Free software, sharing knowledge, building tools that last. There are two models in this industry: one that treats hardware as consumable and software as leverage to sell more of it, and one that builds open tools designed to keep hardware alive. The Open Home Foundation builds open software and open hardware. odio does the same thing at the audio layer. That’s not a coincidence, that’s a shared set of values.

I went to State of the Open Home last week in Utrecht, and I was really glad to be there. Hearing the talks, meeting community members who share the same concerns about freedom, privacy, and sustainability. The whole event was framed around building in the open and sustainability. That’s exactly what odio has been about since 2020, and how I’ve kept my multimedia setup running since 2013.

I also heard about Sendspin, an open standard for synchronized multi-room audio: a proof of concept for a Sendspin on odio is on the roadmap.

The documentation

The Medium series tells the story of how odio was built, article by article, decision by decision, over six years. It was never meant to be reference documentation. If you want to understand why PulseAudio instead of ALSA, or why everything runs in a systemd user session instead of as root, the articles are the right place. They explain the reasoning.

But if you want to install odio and use it, you need something structured around what you’re trying to do, not the order I built it.

docs.odio.love is that reference. It covers:

Getting started. Installation (both flash and curl), how the stack works, the architecture.

Control. The embedded web UI built into go-odio-api, the odio PWA for managing multiple nodes from your phone, and the Home Assistant integration where each node appears as a full HA device with media players, Bluetooth controls, service switches, and power management, all updated in real time over SSE.

Features. Each protocol documented independently: Bluetooth, AirPlay, Spotify Connect, UPnP/DLNA with Tidal and Qobuz, Snapcast multi-room, Audio CD, USB auto-play, PulseAudio TCP network audio.

Use cases. How your existing devices work with odio: your desktop sending audio to an odio node or running go-odio-api itself, your NAS hosting the library while Pi nodes play, your HTPC running Kodi and go-odio-api next to an odio node, your phone as a control surface. Plus integration guides for Navidrome and Music Assistant, How to add extensions, based on users feedback.

API. The full go-odio-api reference: MPRIS, PulseAudio, systemd, Bluetooth, power, Zeroconf, SSE events.

Ecosystem. Multiple repositories, each documented independently because each is usable independently. go-odio-api is the core, but go-mpd-discplayer works without it, odio-ha works without the PWA, the installer works without the flash image. Bricks, not a monolith.

The articles tell the story. The docs answer the question.

odio is in open beta. Flash an image, run the installer, or just read the docs. If you test it on hardware I haven’t tested, report it.

curl -fsSL https://beta.odio.love/install | bash

https://beta.odio.love/odio.rpi-imager-manifest

https://github.com/b0bbywan/odios/releases/tag/2026.4.0rc6

odio.love — Your Pi. Your music. No expiry date.

Six years of Raspberry Pi audio guides. One install command.

In 2020, during the first COVID lockdown, I published a series of articles on Medium about turning a Raspberry Pi B+ into a complete audio server. Bluetooth A2DP, PulseAudio TCP, MPD, DLNA via upmpdcli, AirPlay with Shairport Sync, Spotify Connect, Audio CD, USB auto-play, Snapcast multi-room, and eventually PipeWire. Thirteen articles, in total each one a dedicated feature, each one a pile of apt install, config files, udev rules, systemd units, and hard-won debugging.

It worked. The Pi B+ from 2014 is still running. It went through four major Debian upgrades without a reinstall. Total hardware cost including DAC, Bluetooth dongle, CD drive, case and cables: €164.

But let’s be honest: nobody is going to follow 13 articles to reproduce this setup.

The gap between a guide and a product

The articles are complete, and they’re in order for a reason. Follow them from Part 1 to Part 12 and you’ll get a working setup. But that’s still a lot of guides to follow by hand, each with config files to adapt to your hardware, your Debian version, your DAC. The series started on Buster, got updates for Bookworm, and some parts now have Trixie-specific adjustments. Configs that worked two years ago need changes that only show up in edit notes.

It works. It’s documented. But it’s a multi-hour manual process, and that’s a barrier most people won’t cross.

odios: the installer

odios is the answer. One command:

curl -fsSL https://beta.odio.love/install | bash

It installs and configures the entire stack: MPD, PulseAudio, Shairport Sync, Snapcast, upmpdcli, BlueZ, spotifyd, go-odio-api, go-mpd-discplayer. It prompts for a target user, creates it if needed, backs up existing configs if they exist, detects the architecture, and runs.

Under the hood, it’s an Ansible playbook vendored into a self-contained tarball. Vendored, because resolving dependencies at install time on a user’s machine is a failure mode, not a feature. Ansible, because idempotent: install and upgrade are the same operation. You can re-run it after a failed network timeout and it picks up where it left off. The same playbook will generate the flash image when it ships.

The playbook barely touches the system. Root-level operations are limited to apt packages, enabling linger for the target user, and a couple of D-Bus and polkit policies. Everything else happens in user space: PulseAudio, MPD, Shairport Sync, go-odio-api, Snapcast, spotifyd, go-mpd-discplayer all run as systemd user services, configured under ~/.config. The installer is a guest on your system, not a landlord.

Five minutes on x86. Fifteen on a Pi 3B+. Up to an hour twenty on a Pi B+ at 800 MHz, but then again, that board is twelve years old and it still gets the job done.

What changed since the articles

The biggest shift is that bash scripts became Go binaries. The CD auto-play that used to be a udev rule chaining a systemd unit chaining a bash script calling mpc is now go-mpd-discplayer: a single daemon that watches for disc and USB insertion, fetches metadata from GnuDB and MusicBrainz, generates CUE sheets, and feeds MPD. The Bluetooth pairing that relied on PIN-based authentication and a pile of bash is now replaced by commercial like pairing handled natively through BlueZ D-Bus APIs.

Those binaries became apt packages, built in CI, published to a dedicated apt repository. A tagged release on GitHub triggers the build pipeline. The package lands in the repo. apt upgrade sees it. No more copy-pasting configs from a blog post.

go-odio-api: the layer that was always missing

The articles covered each service individually. What didn’t exist was a way to control them as a whole. go-odio-api is a REST API written in Go that bridges the entire stack into a single coherent interface. Playback, volume, Bluetooth pairing, systemd services, power management, output routing: all exposed as HTTP endpoints, with SSE for real-time state updates.

It works because of one architectural decision made back in 2020: running everything in a systemd user session. Not root. go-odio-api actually refuses to start as root. From the user session, it has legitimate access to the D-Bus session bus, PulseAudio, MPRIS, BlueZ, logind. No privilege escalation, no setuid. The UNIX model, nothing more.

This is also why there’s no source switching. PulseAudio in the user session is the mixer. MPD, Shairport Sync, Spotify, Bluetooth, Snapcast: they all output to the same PulseAudio sink simultaneously. You don’t select a source. You just play.

The API makes everything else possible. odio-pwa is a Svelte progressive web app that controls all your odio nodes from any browser. odio-ha is a native Home Assistant integration where each node appears as a full HA device: media players, Bluetooth controls, service switches, power management, all as native entities, all updated in real time over SSE.

The API is the product. The clients are replaceable. Build yours.

The result

You run the command. When it finishes, your Pi is an AirPlay receiver, a Spotify Connect device, a Bluetooth speaker, a CD player with cover art and metadata, a UPnP/DLNA renderer with Qobuz and Tidal, a Snapcast multi-room client, a PulseAudio network sink for any Linux machine, and a Home Assistant device you can automate. No account. No cloud. No subscription. After six years without a reinstall, I changed the Pi B+ SD card and ran the same curl | bash. Everything came back up. It's been running daily since.

What’s next

A ready-to-flash SD card image is coming, built from the same Ansible playbook frozen at release time. PipeWire as an experimental audio backend option is in the pipeline. And odio is in open beta: test it on your hardware, report issues, and help grow the compatibility list.

Everything is open source under MIT or BSD 2-Clause. The full guide series is still on Medium for anyone who wants to understand each brick. But now there’s a faster path.

curl -fsSL https://beta.odio.love/install | bash

odio.love — Your Pi. Your music. No expiry date.

In 2020, I published a series of articles about turning a Raspberry Pi B+ into a full-featured audio server. Two of them got the most engagement: Bluetooth (Part 1) and Audio CD (Part 6).

Both guides worked. I used that exact setup for years. But I also listed their limitations at the time: no CD metadata, no cover art in MPD clients, a PIN-based Bluetooth pairing model that modern devices increasingly ignore, and a setup process involving udev rules, systemd units, and bash scripts spread across multiple files that probably discouraged more than a few readers from trying.

Six years later, I’ve rewritten both from scratch in Go. This article covers what changed, why, and how to set it up today.

Audio CD: from bash scripts to go-mpd-discplayer

What the 2020 setup looked like

The original approach chained three components:

1. A udev rule watching /dev/sr0 for audio disc insertion
2. A systemd oneshot service to avoid udev timeout issues
3. A bash script (mpc-cd.sh) that counted tracks with udevadm info, added them one by one to MPD as cdda:///1, cdda:///2, ..., and set the disc speed with eject

It worked reliably. Insert a CD, it plays. Eject, it cleans up the queue.

But it had two real limitations I acknowledged in the article:

No metadata. MPD showed cdda:///1, cdda:///2 in the client. No artist, no album, no track names. I wrote at the time: "What annoys me more is that I don't have tracks tags in M.A.L.P." I knew CDDB could solve it but I didn't know how to feed the metadata back to MPD.

Too many moving parts to set up. A udev rule file, a systemd service file, a bash script with hardcoded paths and device names, MPD configuration changes — and all of this had to be adapted if your device path, MPD port, or MPD instance was different from mine. Same deal with USB really.

What replaced it: go-mpd-discplayer

go-mpd-discplayer is a single Go daemon that replaces all of the above. It handles both audio discs and USB sticks.

Disc detection is done natively through libgudev bindings in Go. The daemon watches for block device changes directly, no more udev rules needed.

Metadata is solved. When a disc is inserted, my go-disc-cuer library reads the disc ID via libdiscid, queries GnuDB and MusicBrainz for metadata, and generates a CUE file with artist, album, and track names. MPD's CUE playlist plugin reads this file and exposes the full tracklist with proper tags in any MPD client. Cover art works too — MPD clients can display album covers through the CUE playlist's as_folder option.

USB sticks are handled by the same daemon. The daemon supports both native MPD mounting and symlink-based mounting for MPD servers that don’t support the neighbors plugin.

Extras that weren’t possible with the bash approach: audio notifications on insert/eject (via PulseAudio or ALSA), configurable disc speed management, automatic MPD reconnection if the connection drops, and a built-in cron scheduler for automated playback (start a webradio at 6:30 on weekdays, play a CD on Saturday morning, etc).

Setup

go-mpd-discplayer requires a few C libraries at runtime and their dev counterparts to compile:

# Debian runtime + build dependencies
sudo apt install \
    libcdparanoia0 libdiscid0 libgudev-1.0-0 \
    libdiscid-dev libgudev-1.0-dev libasound2-dev

Clone and build:

git clone https://github.com/b0bbywan/go-mpd-discplayer.git
cd go-mpd-discplayer
go build -o mpd-discplayer
sudo mv mpd-discplayer /usr/local/bin/

Install the systemd user service:

sudo cp share/mpd-discplayer.service /usr/lib/systemd/user/
systemctl --user daemon-reload
systemctl --user enable --now mpd-discplayer

MPD needs two additions in its config — the cdio_paranoia input plugin for disc playback, and the CUE playlist plugin for metadata and cover art:

input {
    plugin "cdio_paranoia"
}
playlist_plugin {
    name "cue"
    enabled "true"
    as_folder "true"
}

My configuration (~/.config/mpd-discplayer/config.yml):

yaml

gnuHelloEmail: "me@email.me"
gnuDbUrl: "http://uniqcode.gnudb.org"
MPDConnection:
  Type: "unix"
  Address: "/run/user/1000/mpd/socket"
  ReconnectWait: 5
MountConfig: "mpd"
AudioBackend: "pulse"

Using a unix socket for the MPD connection is recommended — it lets mpd-discplayer auto-discover MPD’s music_directory, which it needs to store CUE files and USB symlinks. With a TCP connection you'd have to set MPDLibraryFolder manually.

That’s it. No udev rules to write. No systemd oneshot services. No bash scripts. Insert a CD — it plays with full metadata, track names, and cover art in your MPD client. Thanks to MPD devs for making this possible.

Bluetooth: from PIN codes to remote controlled pairing

What the 2020 setup looked like

The original guide configured the Pi as a Bluetooth audio sink using PulseAudio and a custom Python agent for pairing. The audio part — routing Bluetooth streams through PulseAudio to the HiFiBerry DAC — worked fine and hasn’t fundamentally changed since. Whether you use PulseAudio or PipeWire today (as I covered in Part 10), Bluetooth audio routing is handled the same way.

Configuration wasn’t easy and might have discouraged some once again. But what really didn’t age well is the pairing model.

The PIN code is obsolete. The 2020 guide used a Python Bluetooth agent that prompted for a PIN on pairing. This was already becoming uncommon in 2020 — most modern phones and devices use “Just Works” pairing and simply don’t support PIN entry for A2DP audio connections. Over the years, more and more devices just failed to pair with this setup, especially iPhones.

It took me a quite some thinking to find a solution that would be as user friendly as the pin code was. I ended up copying, the usual flow offered by commercial speakers, and maybe enhancing it.

What replaced it: Odio’s Bluetooth backend

go-odio-api v0.7.0 turns the Pi into something that behaves like a real commercial Bluetooth speaker — the kind you just tap “connect” on from your phone.

Pairing works like any Bluetooth speaker you’d buy. From the Odio web UI, tap the pairing button. A 60-second window opens that accepts any incoming connection — no PIN, no confirmation on the Pi. Your phone sees the device name (configured in BlueZ), taps connect, done. After 60 seconds, the pairing window closes automatically. Exactly like a JBL or a Sonos Roam.

You can control the connected phone from the Pi. This is the part that was simply impossible before. Once a phone connects via Bluetooth, it appears in the Odio UI as a media player — with the current track, artist, album art, play/pause, next/previous, and volume. This works through Bluetooth AVRCP and MPRIS: Spotify, YouTube, BubbleUPnP, any app that exposes media controls over Bluetooth. Volume changes on the phone are reflected in real-time in the UI, and vice versa.

This video shows the full flow — powering on Bluetooth, pairing a phone that was never connected before, seeing it appear as a player with the current song, reporting commands from the phone, controlling playback and volume from the UI, and powering off.

The interface is responsive which might have been more impactul for the video with the complete flow, but screen recording on Gnome is so easy I didn’t think about recording my phone.

Setup

The system-level Bluetooth configuration is minimal. In /etc/bluetooth/main.conf:

[General]
Name=Odio       # Bluetooth name shown during device discovery
Class=0x240428

The Class value identifies the device as an audio receiver (Hi-Fi Audio + Headphones + Audio/Video). This is what makes your phone show the right icon and route audio correctly when connecting.

Make sure your user is in the bluetooth group and that the BlueZ service is running:

sudo usermod -aG bluetooth $USER
sudo systemctl enable --now bluetooth

On the Odio side, there’s nothing to configure — the Bluetooth backend is enabled by default. If Odio detects a BlueZ adapter, it exposes the pairing controls in the web UI and starts handling connections, and you can control every steps on Odio built-in UI. or the Odio API. Or soon on Home Assistant.

No Python agent. No PIN configuration. The audio routing itself — whether through PulseAudio or PipeWire — is unchanged from the 2020 setup. What Odio replaces is the pairing and control layer on top of it.

If you need audio notifications for bluetooth as in my video, you can still use the udev trick from my previous article. Odio should eventually get its own audio notification system.

The bigger picture: Odio

Both of these replacements are part of a broader project. After years of running this setup with scattered scripts, multiple systemd services, SSH-based management, and fragile glue code, I built Odio — a single Go daemon that exposes your entire Linux multimedia stack over HTTP.

Beyond Bluetooth, Odio handles:

• MPRIS player control — auto-discovers all media players (Spotify, VLC, Firefox, MPD, Kodi) via D-Bus
• PulseAudio/PipeWire — global and per-app volume control, pure Go, no libpulse dependency
• systemd services — whitelist-based start/stop/restart of user services from your phone
• SSE event stream — real-time push updates, no polling
• Built-in web UI + PWA — manage multiple machines from your phone
• Home Assistant integration — odio-ha (HACS custom component, SSE-based, no polling)

It runs on my 10-year-old Raspberry Pi B+ at <50ms p95 response time, 0% CPU idle, 2% top under activity, <20Mo RAM. Pre-built binaries and packages available for amd64, arm64, armv7hf, armhf, plus Docker multi-arch images on ghcr.io/b0bbywan/go-odio-api:latest.

No root. No cloud. No subscription. 100% local and free.

odio - Open-source Raspberry Pi audio streamer. Self-hosted, Home Assistant native.

What’s next

If you followed the original guide series, here’s where the 2026 stack stands:

• Audio server: PulseAudio → PipeWire + pipewire-pulse (Part 10)
• Bluetooth: PIN agent → Odio Bluetooth backend
• Audio CD: udev + systemd + bash → go-mpd-discplayer
• USB sticks: udev + systemd + bash → go-mpd-discplayer
• Multiroom: not covered → Snapcast (Part 8)
• Remote control: SSH + scripts → Odio web UI + Home Assistant

The parts that haven’t changed: MPD, shairport-sync, spotifyd, upmpdcli. They still work exactly as described in the original articles. The HiFiBerry DAC+ Pro still outputs to the same amplifier. The Pi is still in its wooden case.

What changed is everything around them — the glue, the control layer, the integration. That’s what was always missing, and that’s what Odio is for.

• go-odio-api: https://github.com/b0bbywan/go-odio-api
• go-mpd-discplayer: https://github.com/b0bbywan/go-mpd-discplayer
• odio-ha (Home Assistant): https://github.com/b0bbywan/odio-ha
• Full guide series: Introduction

This is Part 11 of my Raspberry Pi audio server guide. The Pi B+ in the wooden case is now 10 years old, has been through 4 major Debian upgrades, and has never been reinstalled since 2020. Total cost including DAC, Bluetooth dongle, CD drive, RCA cable, power supplies and case: €164.

For over a decade, I’ve kept old hardware alive on Linux: homemade NAS and HTPC since 2013, a Raspberry Pi B+ audio server running 24/7 since 2020 that I documented here. Big thanks to the Debian and Openmediavault projects to make this possible.

Like many, I built a multimedia setup I’m proud of. But cleanly integrating it into Home Assistant always felt hacky, with scattered integrations, SSH scripts, and fragile glue.

go-odio-api v0.4 is built for people like us. An ultra-lightweight Go daemon exposing a clean REST API to control everything in your Linux user session: MPRIS players (Spotify, VLC, Firefox, MPD), PulseAudio/PipeWire, systemd user services. No root. No hacks. Just Linux primitives.​

The 3 Pillars (Modular Backends)

1. MPRIS Control (enabled by default)

Lists all compatible players in real time: Spotify, VLC, Firefox, MPD (with mpd-mpris or mpDris2), etc.

Full actions: play/pause/stop/next/prev, volume, seek, shuffle/loop

GET /players # instant inventory
POST /players/{player}/play
POST /players/{player}/volume # {“volume”: 0.5}
POST /players/{player}/seek # {“offset”: 1000000}

2. PulseAudio/PipeWire Management (enabled by default)

Server info, client listing, volume/mute per client or general output in real time. Limited PipeWire support via pipewire-pulse

Endpoints:

GET /audio/server
POST /audio/server/volume # {“volume”: 0.5}
GET /audio/clients
POST /audio/clients/{client}/mute 

3. systemd USER Services (opt-in, security-critical, central to power)

This backend is a real game-changer — and potentially the riskiest if I screw up the security. But it’s absolutely essential for home automation power users because you need to start/stop/restart services remotely: launching Kodi media centers, firing up Firefox kiosks for Netflix/YouTube, restarting pulseaudio, MPD or shairport-sync when they glitch. Here’s the idea.

How it works (explicit whitelist required):

systemd:
 enabled: true
 user:
   — mpd.service # your music daemon (w/ MPRIS)
   — shairport-sync.service # AirPlay receiver (see my Medium article) 
   — spotifyd.service # headless Spotify (needs MPRIS build)
   — firefox-kiosk@netflix.com.service # Netflix kiosk → auto MPRIS player
   — firefox-kiosk@youtube.com.service # YouTube kiosk → auto MPRIS player
   — kodi.service # full media center (w/ MPRIS addon)
   — vlc.service # VLC daemon
 system: # monitoring only!
 — bluetooth.service # watch system-wide BT status
 — upmpdcli.service # UPnP renderer

Endpoints:

GET /services # ALL whitelisted units + real-time status
POST /services/user/mpd.service/start # launch music daemon
POST /services/user/kodi.service/restart # reboot media center 
POST /services/user/firefox-kiosk@netflix.com.service/stop # kill Netflix kiosk

The Security Model

Layer 1 is dead simple: systemd backend is disabled by default. You must explicitly set systemd.enabled: true AND provide a whitelist of units in config.yaml. No units listed = zero exposure. That’s the bare minimum.

The real protection: Odio enforces user-session mutations only through a an application-layer lockdown, regardless of your system configuration.

Let’s say you messed up your dbus policies through SSH trying to let regular users start system services, or your polkit rules are wide open, Odio’s will still refuses to execute the operation.

You can monitor system-wide units like bluetooth.service or upmpdcli.service (they show live status in GET /services), but never start/stop/restart them. For that, you’ll still need SSH and a CLI.

Remote Kodi restarts, Netflix kiosk launches, MPD service restarts. All possible without opening a giant systemd security hole. Application-layer enforcement makes it safe.
Other protections:

• bind: localhost by default, single interface or all interfaces, exposing Odio is your choice.
• Odio opens only the required sytemd bus based on config
• Odio throughs a fatal error if you try to run it as root.

There’s no authentication, yet, but Odio is meant for trusted LAN only anyway, not Internet exposure.

Without this backend secured properly, you’d be screwed for real home automation use cases. With it, I really hope every one can hack around safely.

Why This Design?

Odio is built around the principle of “dumb core, smart integrations” Unix style. The API stays deliberately simple, stable, and reliable. The real magic comes from the integrations.

The User Session Bet

The architecture makes a critical choice: all multimedia services run as systemd user units (systemctl --user), not system-wide daemons.

Why? Because this pattern has been a Linux best practice since systemd v208. Media services handle per-user resources: audio sinks, display sessions, D-Bus contexts, that belong in user space.

This is the key unlock: by running everything in the user session, Odio talks to a single, unified D-Bus session bus. PulseAudio/Pipewire, MPRIS players (Spotify, VLC, Firefox, MPD, Kodi), user systemd units, all expose an interface on that bus.
Odio doesn’t need to know what Spotify is. Or VLC. Or your custom MPD setup. It just listens to the D-Bus session for MPRIS-compatible players and exposes them via HTTP. You add a new player? It shows up automatically. Zero code change. Zero config.
This is what makes Odio universal without being bloated.

Test in 2 Minutes

Build from source (no prebuilt binaries on purpose for now):

git clone https://github.com/b0bbywan/go-odio-api
cd go-odio-api
go build -o odio-api .
./odio-api

Or Docker (build your own image):

git clone https://github.com/b0bbywan/go-odio-api
cd go-odio-api 
docker build -t odio-api .
docker compose up

Immediate test:
Start a youtube or vlc video, spotify or mpd player and test

curl http://localhost:8018/players # your MPRIS players
curl http://localhost:8018/audio/clients # your Pulse clients
curl -X POST http://localhost:8018/players/mpd/pause # it works

Installation: systemd user service

# ~/.config/systemd/user/odio-api.service
[Unit]
Description=Odio API
After=sound.target network-online.target
Wants=sound.target network-online.target

[Service] 
ExecStart=/usr/local/bin/odio-api
Restart=always
RestartSec=12

[Install]
WantedBy=default.target

systemctl --user enable --now odio-api.service

Integrations & Roadmap

Odio’s real power comes from integrations. The API is just plumbing infrastructure. The magic happens when you connect it to actual control interfaces.

odio-ha: The Home Assistant Integration

I’ve already built the first proper integration to prove what go-odio-api can do: odio-ha.

It exposes:

• Audio control: media_player.odio_audio_receiver for global PulseAudio/PipeWire volume/mute
• Per-service control: separate media_player per systemd service (mpd, kodi, shairport-sync, etc.) with power on/off, volume, state tracking
• MPRIS players (in progress): auto-discovered players (Spotify, VLC, Firefox, MPD) with full playback control and metadata

The real power — integration inheritance:

Once odio-ha exposes your services, you can map them to native HA integrations. Example: MPD runs on your audio server (Odio manages the service), but you want rich features (playlists, album art). Just map the mpd odio service to your existing mpd integration when you set up Odio-ha Integration

• Odio handles service lifecycle (start/stop/restart)
• HA’s MPD integration handles rich playback
• Everything centralized on the right host — your media server

Same for Kodi, Spotify Connect, Snapcast, or any player. Odio becomes the hub that makes all your HA integrations point to the correct machine.

All local. No cloud. No SSH scripts. Automations and voice control just work.

Current state: odio-apiv0.4 + odio-hav0.2.2 (add the repository in HACS) gives you clean control over audio and services.

What’s next

Bluetooth Backend (target v0.5): Turn your Linux box into a fully controllable Bluetooth speaker:

• Toggle Bluetooth power, pairing mode via API
• Accept connections from phones, tablets, laptops
• Playback control and metadata exposed through MPRIS (play/pause/next/prev, track info)
• The speaker appears as a media_player entity in Home Assistant via odio-ha
• Full remote control: no bluetoothctl/bt-agent/custom script hell

Fake a commercial Bluetooth speaker, but with full API control

Built-in dashboard (target v0.6):

Simple web UI served by go-odio-api itself on http://localhost:8018/ui/. I don’t need to tell more, just let screenshot do the talking. There’s a good chance it becomes my HTPC homepage at login.

PR are on the way !

Later: SSE, Authentication, Wayland Remote Control, Photos Casting…

Join the Project

Odio is very early stage. I pushed the very first commit on January 25, 2026, barely three weeks ago. It’s a Proof of Concept and experiment with Claude Code that went much better than expected. Video players weren’t even in the initial scope.

v0.4.0 works out of the box, but there’s a long road ahead. Expect bugs. I’ve mobilized 12 years of Linux multimedia tinkering and 15 years of startup experience to turn that POC into production-grade software: low footprint and portability across architectures and distributions for my old hardware, increasing test coverage since I broke v0.1.2, exhaustive config/README, and solid debug logs for integration developement... I’m building this to be as universal and lasting as possible, not just for my use case, but for yours too. And I can’t do this alone.

I need your help to keep this on the right path.

Does it work on your setup? What breaks? What’s missing? What pain points does your current stack have that we could solve together?

Try it: github.com/b0bbywan/go-odio-api - github.com/b0bbywan/odio-ha
Run it on your hardware. Tell me what works and what doesn’t. Show me your setup. If you want to contribute code, even better. Go is a wonderful language for this use case.

This is what I want to build: the multimedia remote platform Linux has been missing. Universal. Local. Free. Built on stable primitives that already work.

But it only becomes that if it solves your problems, not just mine.

Let’s build it together.

odio - Open-source Raspberry Pi audio streamer. Self-hosted, Home Assistant native.

Fun fact: no me di cuenta de que “Odio” significa hate en español, pero me encanta el nombre, y hasta hice que el número de puerto coincidiera con él, así que lo mantendré.

Part 10 — Replacing a PulseAudio server with PipeWire

Introduction

In a previous article, I explained how to switch a PulseAudio TCP client to PipeWire. This time, we’ll focus on the server side.

To be fully transparent, I haven’t yet migrated my main Raspberry Pi to PipeWire — I first tested everything on an older Raspberry Pi B with headphones to make sure nothing breaks. The goal here is simple: replace PulseAudio with PipeWire on the audio server without breaking anything in the existing setup.

PipeWire itself is the audio engine. It does not speak the PulseAudio protocol by default. pipewire-pulse runs on top of PipeWire to implement the PulseAudio protocol and replace the PulseAudio daemon.

With pipewire-pulse :

• PulseAudio clients will be able to communicate with PipeWire
• TCP connections work exactly like before
• MPD, DNLA, Snapcast, and even bluetooth keep working as before

1. Replace Pulseaudio server by Pipewire, pipewire-pulse and Wireplumber

Let’s start by stopping PulseAudio, installing Pipewire, before definitely removing PulseAudio

$ systemctl --user disable --now pulseaudio.socket pulseaudio.service
$ sudo apt install pipewire-pulse pipewire wireplumber
$ systemctl --user enable --now pipewire.socket pipewire.service pipewire-pulse.socket pipewire-pulse.service wireplumber.service
$ sudo apt purge --auto-remove pulseaudio

Then edit /etc/pipewire/pipewire-pulse.conf or ~/.config/pipewire/pipewire-pulse.conf.

The important parts in this file are:

• uncommented “tcp:4713” in pulse.properties { server.address [ ] }
• new { cmd = “load-module” args = “module-zeroconf-publish” flags = [ ] } in pulse.cmd = [ ]

# PulseAudio config file for PipeWire version "1.2.4" #
#
# Copy and edit this file in /etc/pipewire for system-wide changes
# or in ~/.config/pipewire for local changes.
#
# It is also possible to place a file with an updated section in
# /etc/pipewire/pipewire-pulse.conf.d/ for system-wide changes or in
# ~/.config/pipewire/pipewire-pulse.conf.d/ for local changes.
#

context.properties = {
    ## Configure properties in the system.
    log.level       = 0
}

context.spa-libs = {
    audio.convert.* = audioconvert/libspa-audioconvert
    support.*       = support/libspa-support
}

context.modules = [
    { name = libpipewire-module-rt
        args = {
            nice.level   = -11
        }
        flags = [ ifexists nofail ]
    }
    { name = libpipewire-module-protocol-native }
    { name = libpipewire-module-client-node }
    { name = libpipewire-module-adapter }
    { name = libpipewire-module-metadata }
    { name = libpipewire-module-protocol-pulse
        args = {
        }
    }
]

# Extra scripts can be started here. Setup in default.pa can be moved in
# a script or in pulse.cmd below
context.exec = [
]

# Extra commands can be executed here.
#   load-module : loads a module with args and flags
#      args = "<module-name> <module-args>"
#      ( flags = [ nofail ] )
pulse.cmd = [
    { cmd = "load-module" args = "module-always-sink" flags = [ ] }
    { cmd = "load-module" args = "module-device-manager" flags = [ ] }
    { cmd = "load-module" args = "module-device-restore" flags = [ ] }
    { cmd = "load-module" args = "module-stream-restore" flags = [ ] }
    { cmd = "load-module" args = "module-zeroconf-publish" flags = [ ] }
]

stream.properties = {
}

pulse.properties = {
    # the addresses this server listens on
    server.address = [
        "unix:native"
        "tcp:4713"                         # IPv4 and IPv6 on all addresses
    ]
}

# client/stream specific properties
pulse.rules = [
]

Since we only modified PipeWire PulseAudio configuration, restarting pipewire-pulse is sufficient here.

$ systemctl --user restart pipewire-pulse.service
$ systemctl --user status pipewire-pulse.service 
● pipewire-pulse.service - PipeWire PulseAudio
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-12-30 03:12:00 CET; 40min ago
 Invocation: 6342cff7ad284f69a96be05adc4f1a13
TriggeredBy: ● pipewire-pulse.socket
   Main PID: 554 (pipewire-pulse)
      Tasks: 3 (limit: 379)
        CPU: 5.335s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire-pulse.service
             └─554 /usr/bin/pipewire-pulse

déc. 30 03:12:00 rasponkyold systemd[519]: Started pipewire-pulse.service - PipeWire PulseAudio.
déc. 30 03:12:09 rasponkyold pipewire-pulse[554]: mod.zeroconf-publish: error id:24 seq:76 res:-2 (Aucun fichier ou dossier de ce nom): enum params id:15 (Spa:Enum:P>
déc. 30 03:12:09 rasponkyold pipewire-pulse[554]: mod.zeroconf-publish: error id:24 seq:78 res:-2 (Aucun fichier ou dossier de ce nom): enum params id:17 (Spa:Enum:P>
déc. 30 03:13:02 rasponkyold pipewire-pulse[554]: mod.zeroconf-publish: error id:44 seq:189 res:-2 (Aucun fichier ou dossier de ce nom): enum params id:7 (Spa:Enum:P

The mod.zeroconf-publish error you can see might happen at startup, but it does not prevent the module from being loaded eventually

$ pactl list modules | grep -A7  zeroconf
 Name: module-zeroconf-publish
 Argument: 
 Usage counter: n/a
 Properties:
  module.author = "Sanchayan Maity <sanchayan@asymptotic.io"
  module.description = "mDNS/DNS-SD Service Publish"
  module.version = "1.4.2"

Can we check on the pi if our remote clients managed to connect ? Sure, wpctl is a cli interface for WirePlumber:

$ wpctl status
PipeWire 'pipewire-0' [1.4.2, pi@rasponkyold, cookie:554372954]
 └─ Clients:
        34. pipewire                            [1.4.2, pi@rasponkyold, pid:784]
        35. pipewire                            [1.4.2, pi@rasponkyold, pid:784]
        38. pipewire                            [1.4.2, pi@rasponkyold, pid:780]
        43. WirePlumber [export]                [1.4.2, pi@rasponkyold, pid:972]
        65. WirePlumber                         [1.4.2, pi@rasponkyold, pid:972]
        67. wpctl                               [1.4.2, pi@rasponkyold, pid:2325]
        83. PipeWire                            [1.4.2, bobby@bobby-desktop, pid:3297]

Audio
 ├─ Devices:
 │      95. Audio interne                       [alsa]
 │      96. Audio interne                       [alsa]
 │  
 ├─ Sinks:
 │  *   94. Audio interne Stéréo              [vol: 1.00]
 │  
 ├─ Sources:
 │  
 ├─ Filters:
 │  
 └─ Streams:
        41. PipeWire                                                    
             97. output_FL       > bcm2835 Headphones:playback_FL [init]
             99. output_FR       > bcm2835 Headphones:playback_FR [init]

Video
...

Settings
 └─ Default Configured Devices:
         0. Audio/Sink    alsa_output.platform-2000b840.mailbox.stereo-fallback

# Inspect the Pipewire stream
$ wpctl inspect 41
id 41, type PipeWire:Interface:Node
    adapt.follower.spa-node = ""
    application.id = "org.pipewire.PipeWire"
    application.language = "fr_FR.UTF-8"
  * application.name = "PipeWire"
    application.process.binary = "pipewire"
    application.process.host = "bobby-desktop"     <---
    application.process.id = "3297"
    application.process.machine-id = "10b867c6818e48b2a437a18888026b69"
    application.process.user = "bobby"
    application.version = "1.4.9"
  * client.api = "pipewire-pulse"                  <---
  * client.id = "83"
    clock.quantum-limit = "8192"
  * factory.id = "7"
    library.name = "audioconvert/libspa-audioconvert"
  * media.class = "Stream/Output/Audio"
    media.name = "Tunnel for bobby@bobby-desktop"  <---
    node.autoconnect = "true"
    node.dont-reconnect = "true"
    node.latency = "1200/48000"
    node.loop.name = "data-loop.0"
  * node.name = "PipeWire"
    node.rate = "1/48000"
    node.want-driver = "true"
    object.register = "false"
  * object.serial = "210"
    pipewire.client.access = "restricted"
    port.group = "stream.0"
    pulse.attr.maxlength = "4194304"
    pulse.attr.minreq = "4800"
    pulse.attr.prebuf = "9604"
    pulse.attr.tlength = "14400"
    pulse.corked = "true"
    pulse.server.type = "tcp"                     <--- 
    stream.is-live = "true"
    target.object = "alsa_output.platform-2000b840.mailbox.stereo-fallback"
    window.x11.display = ":0"

Looks like the desktop reconnected seemlessly on the new pipewire-pulse sink, great !

2. Check server is available on clients

Let’s see on the desktop if it really works: First, we can see our new PipeWire sink is now exposed on zeroconf

$ avahi-browse -a |grep pulse
...
+ enp2s0 IPv4 pi@rasponkyold: Audio interne St__r__o        _pulse-sink._tcp     local
...

$ pactl list sinks
...
Destination #203
 État : SUSPENDED
 Nom : tunnel.rasponkyold.local.alsa_output.platform-2000b840.mailbox.stereo-fallback
 Description : Audio interne Stéréo on pi@rasponkyold
 Pilote : PipeWire
 Spécification de l’échantillon : s16le 2ch 48000Hz
 Plan des canaux : front-left,front-right
 Module du propriétaire : 4294967295
 Sourdine : non
 Volume : front-left: 65536 / 100% / 0,00 dB,   front-right: 65536 / 100% / 0,00 dB
         balance 0,00
 Volume de base : 65536 / 100% / 0,00 dB
 Source du moniteur : tunnel.rasponkyold.local.alsa_output.platform-2000b840.mailbox.stereo-fallback.monitor
 Latence : 0 usec, configuré 0 usec
 Marqueurs : NETWORK DECIBEL_VOLUME LATENCY 
 Propriétés :
  audio.format = "S16LE"
  audio.rate = "48000"
  audio.channels = "2"
  audio.position = "[FL,FR]"
  node.name = "tunnel.rasponkyold.local.alsa_output.platform-2000b840.mailbox.stereo-fallback"
  device.description = "Audio interne Stéréo on pi@rasponkyold"
  node.virtual = "true"
  node.network = "true"
  media.class = "Audio/Sink"
  media.name = "pulse"
  stream.is-live = "true"
  node.want-driver = "true"
  node.autoconnect = "true"
  port.group = "stream.0"
  adapt.follower.spa-node = ""
  object.register = "false"
  factory.id = "7"
  clock.quantum-limit = "8192"
  node.loop.name = "data-loop.0"
  library.name = "audioconvert/libspa-audioconvert"
  client.id = "91"
  object.id = "75"
  object.serial = "203"
 Formats :
  pcm

3. Bluetooth

Good news ! Everything from my Bluetooth article from 2020 still applies and works with pipewire-pulse ! Of course, skip the part where you install pulseaudio. Existing PIN-based connections continue to work, on Android at least.
Now WirePlumber automatically manages routing bluetooth audio streams within PipeWire, as we can see below:

$ wpctl status
PipeWire 'pipewire-0' [1.4.2, pi@rasponkyold, cookie:*********]
 └─ Clients:
        40. pipewire                            [1.4.2, pi@rasponkyold, pid:573]
        73. WirePlumber [export]                [1.4.2, pi@rasponkyold, pid:2094]
        81. Snapcast                            [1.4.2, pi@rasponkyold, pid:1993]
        89. WirePlumber                         [1.4.2, pi@rasponkyold, pid:2094]
        95. pipewire                            [1.4.2, pi@rasponkyold, pid:2188]
        97. pipewire                            [1.4.2, pi@rasponkyold, pid:2188]
       110. wpctl                               [1.4.2, pi@rasponkyold, pid:2198]

Audio
 ├─ Devices:
 │      63. Audio interne                       [alsa]
 │      90. Audio interne                       [alsa]
 │     102. Pixel 6a                            [bluez5]
 │  
 ├─ Sinks:
 │  *   118. Audio interne Stéréo              [vol: 1.00]
 │  
 ├─ Sources:
 │  
 ├─ Filters:
 │  
 └─ Streams:
        45. bluez_input.C8_2A_DD_A7_D5_0D.2                             
             48. output_FR       > bcm2835 Headphones:playback_FR [active]
            104. output_FL       > bcm2835 Headphones:playback_FL [active]
        ...

Video
...

Settings
 └─ Default Configured Devices:
         0. Audio/Sink    alsa_output.platform-2000b840.mailbox.stereo-fallback

This shows the phone connected as a bluez5 device, with WirePlumber
automatically routing the Bluetooth audio stream to the default ALSA sink.

Conclusion

Replacing a PulseAudio TCP server with PipeWire turned out to be much easier than expected.
Thanks to pipewire-pulse, all existing clients keep working — TCP reconnections, Bluetooth audio, MPD, and others. No app or client needs any modification.

From the outside, nothing really changes, which is perfect when swapping out a core component like the audio server.
Under the hood, though, you now have a modern, flexible PipeWire stack that provides lower latency, better device management, and full PulseAudio compatibility.

This new base will help push the Raspberry Pi multiroom system even further — and that’s exactly what the next article will explore.

Part 9 — MultiRoom (Snapcast)

Snapcast is one of the most reliable and elegant ways to build a perfectly synchronized multi-room audio system. Snapcast guarantees sample-accurate playback, scales to many rooms, and is extremely lightweight on the client side, making it ideal for old Raspberry Pis (Pi B+, Pi Zero, Pi 2).

This guide walks you through how to make Snapcast fits into a NAS + Raspberry Pi architecture, and how to set it up ith MPD, Spotify, AirPlay, and PipeWire, with all differences between Debian 12 (Bookworm) and recently published Debian 13 (Trixie).

1. Why Snapcast?

I initially tried to do everything directly on the Raspberry Pi with MPD, Spotifyd and PipeWire, but I kept getting random audio cracks — especially every time Spotifyd loaded the next track. Old ARMv6 boards just can’t seem to keep up with modern audio stacks.

That’s the moment I decided to stop fighting the hardware and move the heavy work to my NAS, keeping the Raspberry Pi B+ as an ultra-light Snapclient endpoints.

Snapcast solves all of these at once:

Here are main Snapcast main components :

• Snapclient (Raspberry Pi): Plays audio from Snapserver with perfect sync
• Snapserver (NAS): Mixes and distributes all audio streams from various sources: MPD, Spotify, AirPlay, PipeWire, etc

2. Installing Snapserver on Debian 12 & 13

Debian 12 (Bookworm)

Debian 12 ships Snapcast 0.30 in backports, or 0.26, which are too old because they lack AddStream / RemoveStream features which are mandatory for PipeWire source auto-management (7).

You need at least Snapcast 0.31 from GitHub.

$ wget https://github.com/snapcast/snapcast/releases/download/v0.31.0/snapserver_0.34.0-1_amd64_bookworm.deb
$ sudo dpkg -i snapserver_0.31.0-1_amd64_bookworm.deb

Debian 13 (Trixie)

Debian 13 ships Snapcast 0.31 natively, just install it.

$ sudo apt install snapserver

We’ll also install Snapweb to control our streams:

$ wget https://github.com/snapcast/snapweb/releases/download/v0.9.3/snapweb_0.9.3-1_all.deb
$ sudo dpkg -i snapweb_0.9.3-1_all.deb

Edit /etc/snapserver.conf:

[server]

[http]
enabled = true
bind_to_address = 0.0.0.0
doc_root = /usr/share/snapweb
[tcp]
enabled = true
bind_to_address = 0.0.0.0

This enables:

• Snapweb UI (on port 1780)
• TCP stream interface (port 1704)

3. Adding MPD as a Snapcast Stream

Configure MPD FIFO Output

FIFO output is the classic and most reliable way to feed MPD into Snapcast. It’s simple and low-overhead.

Edit /etc/mpd.conf:

audio_output {
        type            "fifo"
        name            "SnapMPD"
        path            "/tmp/mpdfifo"
        format          "48000:16:2"
        mixer_type      "software"
}

And restart MPD

$ sudo systemctl restart mpd.service

Add it to Snapserver

In /etc/snapserver.conf under [stream], add:

[stream]
# ...
source = pipe:///tmp/mpdfifo?name=MPD&devicename=SnapMPD

And restart snapserver:

$ sudo systemctl restart snapserver

Done — your NAS can now stream its MPD audio to all rooms.

For now, I don’t have any way to stream the Rasperry Pi’s MPD (handling audio CDs and USB sticks) to stream to snapcast, but that may be possible in the future.

4. Adding Spotify (via Librespot)

Install Librespot from source

Debian repositories are too old, so we need to install Rust and Librespot manually:

$ apt-get install build-essential libasound2-dev
$ curl https://sh.rustup.rs -sSf | sh
$ cargo install librespot
$ sudo mv .cargo/bin/librespot /usr/local/bin

This gives you the latest Spotify Connect implementation.

Snapserver Stream

In /etc/snapserver.conf under [stream], add:

[stream]
# ...
source = librespot:///usr/local/bin/librespot?name=Spotify&devicename=SnapSpot&bitrate=320&volume=100&normalize=false

And restart snapserver:

$ sudo systemctl restart snapserver

Now Snapserver exposes a Spotify Connect endpoint in Snapweb.

5. Adding AirPlay (shairport-sync)

Install shairport-sync

Debian 12 → v3.3.8 (AirPlay 1 only)
Debian 13 → v4.3.7 (AirPlay 2 supported !)

$ sudo apt install shairport-sync
$ sudo systemctl disable --now shairport-sync

Shairport will be started by Snapserver, by _snapserver user, so we have to disable the service startup and edit a few dbus policies and add our _snapserver user in the owners of shairport dbus services, as we did on the raspberry in our previous article about AirPlay.

Place the following directives in the <busconfig> section

Edit shairport-sync-dbus-policy.conf:

Debian 12: /etc/dbus-1/system.d/shairport-sync-dbus-policy.conf
Debian 13: /usr/share/dbus-1/system.d/shairport-sync-dbus-policy.conf
Add:

<policy user="_snapserver">
    <allow own="org.gnome.ShairportSync"/>
</policy>

Edit shairport-sync-mpris-policy.conf:

Debian 12: /etc/dbus-1/system.d/shairport-sync-mpris-policy.conf
Debian 13: /usr/share/dbus-1/system.d/shairport-sync-mpris-policy.conf

<policy user="_snapserver">
    <allow own="org.mpris.MediaPlayer2.ShairportSync"/>
</policy>

Restart Dbus:

$ sudo systemctl restart dbus.service

Snapserver Stream

In /etc/snapserver.conf under [stream], add:

[stream]
# ...
source = airplay:///usr/bin/shairport-sync?name=Airplay&devicename=SnapAir&port=5000

And restart snapserver:

$ sudo systemctl restart snapserver

You now have a fully integrated AirPlay endpoint (1 or 2 depending on Debian version).

6. Installing Snapclient on Raspberry Pi

Snapclient doesn’t really benefit from version 0.31 — only Snapserver does. On Debian 12, both Snapclient 0.26 (bookworm) and 0.30 (bookworm-backports) work perfectly fine.

The only real requirement is Snapserver ≥ 0.31 because it restores AddStream and RemoveStream.

Of course, for a multi room setup and the full Snapcast experience, you have to repeat this part on every raspberry behind speakers that you want.

$ sudo apt install snapclient

Use Pulse/PipeWire as backend

Edit /etc/default/snapclient:

SNAPCLIENT_OPTS="--player pulse"

Run Snapclient as a user service

Running Snapclient as a user service ensures PulseAudio/PipeWire is already running before Snapclient starts. The system service starts too early and can fail silently.

$ sudo systemctl disable --now snapclient.service
$ systemctl --user enable --now snapclient.service

7. PipeWire Autodiscovery

PipeWire can automatically detect Snapcast servers and redirect audio streams to them. With this module, any audio played on this machine (browser, apps, system sounds, games, anything) automatically appears as a Snapcast stream on your network. Zero configuration. Very useful for PCs, laptops, HTPCs, etc.

Create:

~/.config/pipewire/pipewire.conf.d/my-snapcast-discover.conf

context.modules = [
{   name = libpipewire-module-snapcast-discover
    args = {
        stream.rules = [
            {   matches = [
                    { snapcast.ip = "~.*" }
                ]
                actions = {
                    create-stream = {
                      node.name = "Snapcast"
                      node.description = "Snapcast Server"
                    }
                }
            }
        ]
    }
}
]

And restart Pipewire

$ systemctl --user restart pipewire-pulse.service

The Snapserver then appears as “Snapcast Server” in your audio outputs.

8. Conclusion

After setting up Snapcast with MPD, Spotify (Librespot), AirPlay, and PipeWire, the results are exactly what I wanted. Old Raspberry Pis like the Pi B+ become stable, low-CPU multiroom endpoints. Audio is perfectly synchronized across rooms, without the cracks and stuttering I had when trying to run everything directly on the Pi.

Snapserver centralizes all sources on the NAS, and Snapclient handles playback reliably.

Management is straightforward: the web interface on http://<nas>:1780 provides full control over streams and clients, and the Snapcast Android app allows easy control from anywhere in the house. You get a list of all Snapclient on your network and can choose which source to play on it.

Combined with PipeWire Snapcast discovery, any desktop or laptop application can become a stream without manual configuration.

Overall, this setup proves that you don’t need new hardware for true multiroom audio. With a NAS as the central hub and lightweight Raspberry Pi clients, even old ARM boards can deliver a rock-solid, fully controllable, multi-source audio system.

Initially, I stuck with Pulseaudio, but as time went on, I encountered more issues with the TCP client, particularly when using streaming services like YouTube. When Fedora 36 introduced Pipewire 0.3.4x with TCP and zeroconf support, I gave it another try.

$ sudo dnf install --allowerasing  pipewire-pulse

Add a few lines in /etc/pipewire/pipewire-pulse.conf to allow your pipewire client to discover the PulseAudio and Airplay Server on the Pi

context.modules = [
# …
{ name = libpipewire-module-protocol-native }
{ name = libpipewire-module-zeroconf-discover
 args = { }
}
{ name = libpipewire-module-protocol-pulse
 args = { }
}]
context.exec = [
# …
 { path = "pactl" args = "load-module module-raop-discover" }
]

Then reboot your system to allow Pipewire to replace Pulseaudio as the sound manager.

You can also use systemd to achieve the same result.

$ systemctl --user disable --now pulseaudio.service pulseaudio.socket
$ systemctl --user enable --now pipewire-pulse.service pipewire-pulse.socket

And waow the difference is really amazing. Switching output is really flawless, the audio starts immediately without any glitches. Pipewire proved to be a significant improvement over Pulseaudio, even though I was relatively content with Pulseaudio’s performance. I had some bad surprises with some Pipewire updates but I’m really happy about it now.

As Pipewire keeps Pulseaudio compatibity, the gnome setting to change the audio output stays the same as before.

This extension can also be noted as it helps changing directly from the activity bar and functions exceptionally well compared to its previous state.

Gnome 43 supports this menu natively, so the extension became useless.

I’ve also successfully transitioned my HTPC server to Debian 11 and wanted to implement the same Pipewire setup. Obviously the procedure is a bit different, and well documented on Debian Wiki. As the wiki states this method isn’t offically supported, but works well enough nonetheless.
We need to add backports repositories if it isn’t done already

/etc/apt/sources.list.d/backports.list

deb http://deb.debian.org/debian bullseye-backports main

First we’ll install pipewire from the backports

$ sudo apt update
$ sudo apt install pipewire-pulse/bullseye-backports pipewire/bullseye-backports pipewire-bin/bullseye-backports libpipewire-0.3-modules/bullseye-backports wireplumber/bullseye-backports

Now we can configure and run Pipewire instead of Pulseaudio.

First copy systemd unit files from doc

$ sudo cp /usr/share/doc/pipewire/examples/systemd/user/pipewire-pulse.* /etc/systemd/user/

Then copy Pipewire configuration file from doc to /etc/pipewire/pipewire-pulse.conf file and make the same configuration changes as described earlier for Fedora.

$ sudo apt install libpipewire-module-raop-discover #Install Airplay Discover Module
$ sudo cp /usr/share/pipewire/pipewire-pulse.conf /etc/pipewire/pipewire-pulse.conf # copy the pipewire-pulse configuration file from doc

Reload the systemd daemon and disable Pulseaudio while enabling Pipewire:

$ systemctl --user daemon-reload
$ systemctl --user disable --now pulseaudio.service pulseaudio.socket
$ systemctl --user enable --now pipewire pipewire-pulse

You can reboot to make sure everything runs fine at boot

I have quite a lot of error when Pipewire starts, but everything seems to be running fine. I tried to follow pipewire wiki for the rt errors without success

$ systemctl --user status pipewire-pulse
sept. 23 21:30:08 htpc pipewire-pulse[885]: mod.rt: Can't find xdg-portal: (null)
sept. 23 21:30:08 htpc pipewire-pulse[885]: mod.rt: found session bus but no portal
sept. 23 21:30:08 htpc pipewire-pulse[885]: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
sept. 23 21:30:08 htpc pipewire-pulse[885]: mod.rt: could not make thread 903 realtime using RTKit: Permission non accordée
sept. 23 21:30:08 htpc pipewire-pulse[902]: 536870912
sept. 23 21:30:11 htpc pipewire-pulse[885]: mod.pulse-tunnel: failed to connect: Accès refusé
sept. 23 21:30:11 htpc pipewire-pulse[885]: mod.zeroconf-discover: Can't load module: Opération non permise
sept. 23 21:30:13 htpc pipewire-pulse[885]: mod.pulse-tunnel: underflow

Especially, the mod.zeroconf-discover: Can’t load module: Opération non permise is surprising because the module is working perfectly. Although the zeroconf-discover module is not listed with pactl list modules, my raspberry sink does appear in pipewire. If I remove the module in configuration, the error disappear but so does the sink 🙃

Those errors disappeared later when I upgraded to Debian 12 Bookworm. In this version the backports are not needed.

Part 8 — AirPlay

I also wanted to add AirPlay support to the Raspberry for my friends with Apple devices. It’s also a common service on most open source and commercial audio servers. The way to go is to install Shairport-sync. Installation is pretty easy, but configuration with PulseAudio is a bit tricky.
We’ll want to run Shairport-sync as a user systemd unit with our pi user and configure it to use our PulseAudio server as audio backend to bypass the limitations announced in the documentation.

$ sudo apt install shairport-sync
$ systemctl --user enable shairport-sync

This will copy default systemd unit in ~/.config/systemd/user/shairport-sync.service (if not you’ll have to create it), but we need to make some adjustments to make it work properly:
- Remove the Avahi mentions and User and Group directive which can’t be used within a user sytemd unit.
- Change the install method to default.target instead of multi-user to boot properly with user systemd
- Change restart policy, for some reason Shairport-sync seems to start quicker than PulseAudio and fail to connect to it and start properly at boot.

~/.config/systemd/user/shairport-sync.service

[Unit]
Description=Shairport Sync - AirPlay Audio Receiver
Wants=sound.target
After=sound.target
Wants=network-online.target
After=network.target network-online.target

[Service]
Type=simple
EnvironmentFile=-/etc/default/shairport-sync
ExecStart=/usr/bin/shairport-sync $DAEMON_ARGS 
Restart=always
RestartSec=5

[Install]
WantedBy=default.target

Since we use our user pi instead of default shairport-sync user, we also need to edit a few dbus policies and to add our pi user in the owners of shairport dbus services. Place the following directives in the <busconfig> section

Debian 12 Bookworm: /etc/dbus-1/system.d/shairport-sync-dbus-policy.conf
Debian 13 Trixie: /usr/share/dbus-1/system.d/shairport-sync-dbus-policy.conf

<policy user="pi">
 <allow own="org.gnome.ShairportSync"/>
</policy>

Debian 12 Bookworm: /etc/dbus-1/system.d/shairport-sync-mpris-policy.conf
Debian 13 Trixie : /usr/share/dbus-1/system.d/shairport-sync-mpris-policy.conf

<policy user="pi">
 <allow own="org.mpris.MediaPlayer2.ShairportSync"/>
</policy>

$ sudo systemctl restart dbus

Finally, as we’re used in this seup, we configure shairport-sync to use PulseAudio backend instead of Alsa

/etc/shairport-sync.conf

general = {
 name = "%H"; // This means "Hostname" - see below. This is the name the service will advertise to iTunes.
 output_backend = "pa"; // Run "shairport-sync -h" to get a list of all output_backends, e.g. "alsa", "pipe", "stdout". The default is the first one.
 mdns_backend = "avahi"; // Run "shairport-sync -h" to get a list of all mdns_backends. The default is the first one.
};
pa = {
 server = "127.0.0.1"; // Set this to override the default pulseaudio server that should be used.
 application_name = "Shairport Sync"; //Set this to the name that should appear in the Sounds "Applications" tab when Shairport Sync is active.
};

We can finally start shairport-sync…

$ systemctl --user start shairport-sync.service

And see it running and connected to PulseAudio

$ journalctl --user -u shairport-sync.service
Apr 18 01:05:53 rasponkyo systemd[688]: shairport-sync.service: Consumed 1.607s CPU time.
Apr 18 01:05:53 rasponkyo systemd[688]: Started Shairport Sync - AirPlay Audio Receiver.
$ pactl list clients
Client #20
 Driver: protocol-native.c
 Owner Module: 11
 Properties:
 application.name = "Shairport Sync"
 native-protocol.peer = "TCP/IP client from 127.0.0.1:50616"
 native-protocol.version = "34"
 application.process.id = "2376"
 application.process.user = "pi"
 application.process.host = "rasponkyo"
 application.process.binary = "shairport-sync"
 application.language = "C"
 application.process.machine_id = "94407542ae804e6f9e791df75037e3d2"

Using our new AirPlay server as a PulseAudio sink

Since version 11 PulseAudio natively supports AirPlay servers as sink, so we can use it as a remote sink as we did with PulseAudio TCP.

Then you can go in your sound settings and set the output to your new AirPlay server, running on port 5000.

This schema below is the setup exactly as explained in this guide, but it’s not the one I use today. I had to make a few changes to the initial setup I had in mind because of performances issues.

I had audio cracks and lags with Spotify Connect, MPD, and DLNA of course since UpMPDcli uses MPD as backend, especially at the beginning or end of songs. So I monitored the Pi with htop as I was using it and noticed the pi had a high load average, above 1, because the CPU often reached 100% usage, which meant the Pi wasn’t fast enough to perform all calculations in time to render audio, which is something you really don’t want when dealing with Hi-Fi.

I noticed Pulsaudio and LibreSpot used a lot of CPU while running, around 40% each. But there wasn’t much I could do about it at that time (160kbps with Spotify is poor quality enough). I tried to increasing Pulseaudio and MPD priority in the kernel, which improved things without solving my problem completely. Overclocking the Pi did not help either.

But I also noticed something I could act on : the main MPD instance, unlike the USB one, maintained a CPU usage around 15% when it was supposedly idle and even higher in use, so I concluded it was the satelitte connexion with the NAS MPD which was causing this overload. So I dumped the MPD satellite instance on the Pi and MPD CPU usage dropped significantly, especially when idle : 0%.

I already had the MPD database on my NAS since the satellite mode of the Pi relied on its database so I set the Raspberry PulseAudio sink as MPD audio output on the NAS. Then I just had to replace the Pi address IP by the NAS one in M.A.L.P. and ympd to be able to browse music from MPD on the NAS and play it on the Pi.

Since then, LibreSpot had dropped to 30% and Pulseaudio 10%. I’m not sure it was Pulseaudio and LibreSpot updates which caused this or a DAC driver update, or maybe both, but I’m really happy about it because I could improve Spotify quality to 320kpbs thanks to it.

It was really a win-win since I improved the performance of the Pi, lags and cracks disappeared, without losing any feature in my setup, and the Pi became completely independant from the NAS which makes more sense in my opinion.

Part 7 — Spotify (Raspotify →Spotifyd)

A much appreciated feature in recent connected amplifiers is the ability to play music from streaming services. Even if I have a huge media library, everything is not in it, so I wanted to add support of Spotify on my HiFi server.

The obvious choice was Raspotify, a Raspberry Spotify client based on librespot, an open source Spotify client. However, a premium Spotify account is required.

The installation is very easy :

$ curl -sL https://dtcooper.github.io/raspotify/install.sh | sh

The configuration file is located at /etc/default/raspotify

# /etc/default/raspotify --Arguments/configuration for librespot
# Device name on Spotify Connect
DEVICE_NAME="onkyo-raspotify"
# Bitrate, one of 96 (low quality), 160 (default quality), or 320 (high quality)
BITRATE="160"
# Additional command line arguments for librespot can be set below.
# See `librespot -h` for more info. Make sure whatever arguments you specify
# aren't already covered by other variables in this file. (See the daemon's
# config at `/lib/systemd/system/raspotify.service` for more technical details.)
#
# To make your device visible on Spotify Connect across the Internet add your
# username and password which can be set via "Set device password", on your
# account settings, use ` --username` and ` --password`.
#
# To choose a different output device (ie a USB audio dongle or HDMI audio out),
# use ` --device` with something like ` --device hw:0,1`. Your mileage may vary.
#
#OPTIONS=" --username <USERNAME> --password <PASSWORD>"
# Uncomment to use a cache for downloaded audio files. Cache is disabled by
# default. It's best to leave this as-is if you want to use it, since
# permissions are properly set on the directory `/var/cache/raspotify'.
#CACHE_ARGS=" --cache /var/cache/raspotify"
# By default, the volume normalization is enabled, add alternative volume
# arguments here if you'd like, but these should be fine.
VOLUME_ARGS="--linear-volume --initial-volume=100"
#VOLUME_ARGS="--enable-volume-normalisation --linear-volume --initial-volume=100"
# Backend could be set to pipe here, but it's for very advanced use cases of
# librespot, so you shouldn't need to change this under normal circumstances.
#BACKEND_ARGS="--backend alsa"

First I modified the DEVICE_NAME, which will be the name of the Pi in the Spotify App.

For performance issues, I kept the 160 bitrate, 320 seems too stressful for the Raspberry B+ processor, and I removed the enable-volume-normalisation option which often created annoying pauses or cracks when playing music, especially the ones using silences. I also noticed that the audio quality was way better without it.

Edit 20/04/2021: After an update I noticed pulsaudio and librespot CPU usage had dropped significantly and I can now use the 320 kbps birate without performance issues, which is pretty nice for such an old Raspberry model.

We now have to restart raspotify for the changes to be taken into account

$ sudo systemctl restart raspotify

As you may have noticed, Raspotify use ALSA as audio backend. If you read the rest of this guide, you know I use Pulseaudio and it’s really bad to have a program accessing ALSA directly in this setup. Fortunately there’s a way to configure ALSA to work with Pulseaudio without troubles. All you have to do is add a few lines to /etc/asound.rc

pcm.!default {
 type pulse
}
ctl.!default {
 type pulse
}

I’m afraid I don’t exactly how to restart ALSA without rebooting, but after this when using Raspotify, you can run this command and see ALSA being managed by Pulseaudio

$ pactl list sink-inputs
...
Sink Input #49
 Driver: protocol-native.c
 Owner Module: 11
 Client: 69
 Sink: 0
 Sample Specification: s16le 2ch 44100Hz
 Channel Map: front-left,front-right
 Format: pcm, format.sample_format = "\"s16le\"" format.rate = "44100" format.channels = "2" format.channel_map = "\"front-left,front-right\""
 Corked: no
 Mute: no
 Volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
 balance 0.00
 Buffer Latency: 407709 usec
 Sink Latency: 19516 usec
 Resample method: copy
 Properties:
 media.name = "ALSA Playback"
 application.name = "ALSA plug-in [librespot]"
 native-protocol.peer = "TCP/IP client from 127.0.0.1:57936"
 native-protocol.version = "32"
 application.process.id = "417"
 application.process.user = "raspotify"
 application.process.host = "Ampli-BT"
 application.process.binary = "librespot"
 application.language = "C"
 application.process.machine_id = "94407542ae804e6f9e791df75037e3d2"
 module-stream-restore.id = "sink-input-by-application-name:ALSA plug-in [librespot]"

In January 2022, I experienced issues with Raspotify, the new released versions were too CPU intensive for my old B+. The solution I found was to downgrade to a specific version and prevent it from upgrade using :

$ wget https://github.com/dtcooper/raspotify/releases/download/0.31.3/raspotify_0.31.3.librespot.v0.3.1-19-gbbd575e_armhf.deb
$ sudo dpkg -i raspotify_0.31.3.librespot.v0.3.1–19-gbbd575e_armhf.deb
$ sudo apt-mark hold raspotify

The following version also works but introduces configuration changes I won’t cover here since I changed of software soon after.

Spotifyd

I was not really happy being stuck with an old software version, API changes in Spotify would break my install, so I looked for an alternative to Raspotify. I noticed HifiBerryOS was using Spotifyd, an alternative written in Rust, so I decided to give it a try. Documentation is available here.

First we need to install the appopriate version

$ sudo wget https://github.com/Spotifyd/spotifyd/releases/download/v0.3.3/spotifyd-linux-armv6-slim.tar.gz -P /opt/
$ sudo tar xf /opt/spotifyd-linux-armv6-slim.tar.gz
$ sudo mv /opt/spotifyd /opt/bin

Then we create our configuration file. I assume you already configured Pulseaudio and ALSA together as mentionned above.

$ mkdir /home/pi/.config/spotifyd
$ vim /home/pi/.config/spotifyd/spotifyd.conf

[global]
#username = "USER"
#password = "PASS" # Those are optional if you plan to use it with Spotify Connect
backend = "alsa"
device = "default" # Given by `aplay -L`
mixer = "PCM"
volume-controller = "alsa" # or alsa_linear, or softvol
#onevent = command_run_on_playback_event
device_name = "rasponkyo"
bitrate = 320
#cache_path = "cache_directory"
volume-normalisation = false
normalisation-pregain = 0

We now need a systemd unit to run Spotifyd at boot

$ vim ~/.config/systemd/user/spotifyd.service

[Unit]
Description=A spotify playing daemon
Documentation=https://github.com/Spotifyd/spotifyd
Wants=sound.target
After=sound.target
Wants=network-online.target
After=network-online.target
[Service]
ExecStart=/opt/bin/spotifyd --no-daemon
Restart=always
RestartSec=12
[Install]
WantedBy=default.target

$ systemctl --user daemon-reload
$ systemctl --user enable spotifyd.service
$ systemctl --user start spotifyd.service

We can see spotifyd running in journalctl

$ journalctl -f -u spotifyd.service
Apr 02 13:55:40 rasponkyo systemd[552]: Started A spotify playing daemon.
Apr 02 13:55:41 rasponkyo spotifyd[5985]: Loading config from "/home/pi/.config/spotifyd/spotifyd.conf"
Apr 02 13:55:41 rasponkyo spotifyd[5985]: No username specified. Checking username_cmd
Apr 02 13:55:41 rasponkyo spotifyd[5985]: No username_cmd specified
Apr 02 13:55:41 rasponkyo spotifyd[5985]: No password specified. Checking password_cmd
Apr 02 13:55:41 rasponkyo spotifyd[5985]: No password_cmd specified
Apr 02 13:55:41 rasponkyo spotifyd[5985]: No proxy specified
Apr 02 13:55:41 rasponkyo spotifyd[5985]: Using software volume controller.
Apr 02 13:55:51 rasponkyo spotifyd[5985]: Connecting to AP "ap.spotify.com:443"
Apr 02 13:55:51 rasponkyo spotifyd[5985]: Authenticated as "**************" !
Apr 02 13:55:51 rasponkyo spotifyd[5985]: Country: "FR"
Apr 02 13:55:51 rasponkyo spotifyd[5985]: Using Alsa sink with format: S16

You might have already guessed it since I took the time to write this solution, it does work better than Raspotify without any feature loss, so that’s a great win. Unforunately there aren’t as many configuration possible.

Be aware that since no repository are available for Spotifyd we’ll need to keep an eye on the repository to be informed of new releases. Fortunately Github has a feature exactly for this :

To use Spotify Connect, you need a Spotify application on a computer or phone running on the same network as the Raspberry, and then can redirect the audio output to Raspotify.

Tap the bottom left speaker icon to open the screen below, and select your fresh Raspotify client.

You could argue it’s not really interested when using the computer, since the audio output is already set to the Raspberry pulseaudio sink, but this way you can poweroff your computer after starting your playlist, and take over control on your phone without losing the playlist.

There’s also a way to install a Spotify client in UpMPDCli, the DLNA renderer I talked previously about. It’s pretty convenient to mix songs from Spotify and my NAS, but it’s not exactly a recommanded way to stream from Spotify since it’s using the deprecated libspotify library, so I won’t detail it here.