I gave a Raspberry Pi Zero W a Bluetooth soundbar to drive

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.

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.

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.

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.

Why not just use what already exists

Honest answer: I tried.

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.

So I wrote it.

What zerod is

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.

The API surface is intentionally small:

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.

How it actually plays a stream

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()
                            ▲                                    │
                            └────────── live-refresh task ───────┘

A few details that matter on the Pi Zero:

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.

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]
alsa = "0.9"

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

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

Live-edge starts. When the manifest is live, the player jumps to roughly the third-from-last segment instead of starting from the beginning. Otherwise you spend the first 30 seconds catching up to real-time and the laptop audio is hilariously behind the speaker:

if snap.is_live {
    let n = snap.segments.len();
    if n > 3 {
        next_play_seq = snap.segments[n - 3].seq;
    }
}

Per-stream gain in the loop. Independent from the ALSA mixer — I apply a 0..=100 scale to the i16 samples before they hit the sink. The system volume stays where the soundbar likes it; I attenuate per-stream:

fn apply_gain(samples: &mut [i16], volume_percent: u32) {
    if volume_percent >= 100 { return; }
    let num = volume_percent as i32;
    for s in samples {
        *s = ((*s as i32).saturating_mul(num) / 100) as i16;
    }
}

A saturating_mul keeps me away from i32 overflow on samples near the rails. Divide by 100 stays inside i16. Cheap, predictable, runs fine on a 1GHz ARMv6.

Cross-compiling for the Zero

The Pi Zero W is ARMv6 — arm-unknown-linux-gnueabihf, not aarch64. cross handles most of it, but three things bit me hard enough that they're permanently committed to the per-target Dockerfile:

If you ever cross-compile a Rust daemon for the original Pi Zero and run into the same wall, those three are what I'd check first.

How I actually use it day to day

The Pi is on the LAN as pizero.local. On the MacBook:

export ZEROD_HOST=pizero.local
export ZEROD_BEARER_TOKEN="$(cat ~/.zerod-token)"

Then a typical session looks like:

# pair the soundbar (one-time)
zerod bluetooth scan --timeout-secs 5
zerod bluetooth connect AA:BB:CC:DD:EE:FF


# start the laptop's HLS server 
rockboxd

# tell the Pi to play it
zerod stream play http://macbook.local:7882/hls/audio.m3u8
zerod stream volume set 80

When the soundbar wakes up grumpy after a power cycle:

zerod bluetooth disconnect AA:BB:CC:DD:EE:FF
zerod bluetooth connect    AA:BB:CC:DD:EE:FF

When BlueZ itself gets stuck (it happens, on every Linux distro, forever):

zerod systemd restart bluetooth.service

It's a fresh project — the binary has only been on the Pi for a few days — but so far I haven't had to SSH in once. That was the whole point.

What I'd do differently

A few things I'm already eyeing:

None of those are blocking. It does the one job I gave it, which is all I asked.

Source

github.com/tsirysndr/zerod — MIT, prebuilt tarballs for the ARMv6 / ARM64 / x86_64 / Apple Silicon / Intel Mac matrix on every release tag, brew install tsirysndr/tap/zerod if that's your thing.