I gave a Raspberry Pi Zero W a Bluetooth soundbar to drive - Tsiry Sandratraina<br>Tsiry Sandratraina<br>I gave a Raspberry Pi Zero W a Bluetooth soundbar to drive<br>Tsiry Sandratraina 🦀

June 11, 2026

I've had a Raspberry Pi Zero W sitting under my soundbar for about a year. The job description was simple: be the one device on the soundbar's Bluetooth allowlist so I never have to repair anything, and play whatever audio my MacBook shoves at it. That's it. No screen, no DAC, no hat. Just a tiny board acting as a permanent Bluetooth client.<br>Getting there involved more yak-shaving than I'd like to admit, so I eventually wrote a small Rust daemon to do it. It's called zerod. This post is about why it exists, what it actually does, and how the music ends up in my living room.

The setup, end to end

MacBook (rockbox-zig) ──► HLS (m3u8 + .m4s segments) ──► Pi Zero W (zerod) ──► ALSA ──► bluez-alsa ──► Bluetooth A2DP ──► soundbar

The MacBook runs rockbox-zig, a fork of Rockbox I've been hacking on, with a built-in HLS server bolted to its output stage. So the player itself is the source — no BlackHole loopback, no ffmpeg capture, no second process. It just exposes whatever it's currently decoding as an HLS playlist on the LAN.<br>The Pi pulls that playlist, decodes the AAC segments, and writes PCM into ALSA. ALSA hands it to BlueZ, which streams A2DP to the soundbar.<br>The Pi never disconnects from the soundbar. The MacBook never sees the soundbar at all. The Pi is the only paired device — that's the whole reason the soundbar works reliably. Anyone who's lived with multi-device Bluetooth knows what I'm talking about.<br>Why not just use what already exists<br>Honest answer: I tried.

Snapcast is fantastic but it wants its own server-client world, not "ingest an HLS URL." I'd be running a snapserver on the Mac and a snapclient on the Pi just to move PCM around — and rockbox-zig already speaks HLS.

shairport-sync is great if you want AirPlay, but I wanted the music player itself to be the source of truth, not a shim that re-wraps system audio.

bluealsa + a shell script + a systemd unit is what I ran for months. It worked. It was also impossible to debug from the couch, and every Bluetooth hiccup meant either SSH'ing in or walking over to the Pi.

What I actually wanted was one binary on the Pi that could (a) play an HLS stream to ALSA, (b) let me run bluetoothctl-equivalent commands from my laptop without SSH, (c) restart whatever systemd unit I'd inevitably wedge, and (d) edit snapserver.conf and friends without me opening another shell.<br>So I wrote it.<br>What zerod is<br>One Rust binary. When you run it with no arguments, it's a daemon exposing a gRPC API on port 50151. When you run it with subcommands, it's a CLI that talks to another zerod over the same API. Same binary on both sides.<br>The API surface is intentionally small:

HLS / MPEG-DASH playback — fetch a manifest, follow segments, decode with symphonia, push PCM to a sink.

BlueZ control — scan, pair, connect, disconnect. Just the verbs I actually use.

systemd control — start/stop/restart, restricted to an allowlist in zerod.toml so the daemon can't be turned into a generic remote systemctl.

ALSA volume — get/set any selem on any card.

Remote config edit — atomic read/write of a fixed set of files (snapserver.conf, shairport-sync.conf, etc.), with an optional reload-or-restart of the bound unit after every write.

Auth is a bearer token, three sources in order: zerod.toml, ZEROD_BEARER_TOKEN, or a random 32-byte one generated and logged once at startup. No TLS in v1 — the bind defaults to 0.0.0.0:50151 because I drive it from my laptop, and the bearer is the only line of defence. If the LAN ever stops being trusted, that's what WireGuard is for.<br>How it actually plays a stream<br>The player loop is the only part that's interesting. Everything else is a thin wrapper over a system library.

manifest fetch ──► segment prefetch ──► decode ──► gain ──► sink.write()<br>▲ │<br>└────────── live-refresh task ───────┘

A few details that matter on the Pi Zero:<br>Symphonia, not gstreamer. Pure-Rust decode means no apt install dance, no plugin discovery, no surprise dynamic linking. The binary on the Pi is one file. For HLS-with-AAC-in-m4s that's the common case anyway, and Symphonia handles it cleanly.<br>ALSA directly via alsa-rs, not cpal. This was the war story. On macOS the player uses cpal like any well-behaved cross-platform tool. On Linux, the same code segfaulted inside libasound's PulseAudio plugin on Raspberry Pi OS — cpal's ALSA backend uses mmap mode, and something in the pulse-plugin path doesn't survive contact with it on the Pi. After a couple of evenings of gdb, I gave up trying to fix it in cpal and just went straight to snd_pcm_writei:

[target.'cfg(target_os = "linux")'.dependencies]<br>alsa = "0.9"

[target.'cfg(not(target_os = "linux"))'.dependencies]<br>cpal = "0.15"

That's the entire portability story. The sink trait is identical on both sides; only the implementation...