Episode: 3059
Title: HPR3059: A quick intro to Snapcast
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3059/hpr3059.mp3
Transcribed: 2025-10-24 16:01:42

---

This is Hacker Public Radio episode 3,059 for Thursday, 23 April 2020.
Today's show is entitled A Quick Into To Snapcast.
It is the first show by new host Dan Nixon
and is about five minutes long
and carries an explicit flag. The summary is
a brief overview of Snapcast,
an open-source multi-room audio streaming system this year.
This episode of HPR is brought to you by
An Honesthost.com.
Get 15% discount on all shared hosting
with the offer code HPR15.
That's HPR15.
Better web hosting that's Honest and Fair
at An Honesthost.com.
.
.
.
.
This allows you to take a single audio stream
and distribute it to multiple clients
situated in different physical locations.
The intention is that each client plays the audio in sync with every other client
such that there are no obvious delays
or unwanted effects caused by listening to multiple out-of-sync audio streams.
In an ideal world,
this would allow you to freely walk around the area
covered by the clients and not notice
that you're in fact listening to the audio from several different devices.
The software is split into two components,
the server, snap server,
and the client, snap client.
The server accepts the audio stream from your software of choice
and the client receives audio from the server
and plays it back via audio devices local to the client.
Snapcast is fairly lightweight.
The client will happily run on the likes of a Raspberry Pi B,
which for a while was my go-to device for a client.
It is possible for clients to replace it into logical groups.
For example, it may make sense to have clients in the kitchen and living room
being a group if they're frequently used simultaneously.
The server can also accept multiple streams.
Each client can select a particular stream to play audio from.
All of these features come together to make a quite flexible piece of software
that can be either as simple or as complex as it needs to be.
I'll now attempt to give a quick overview of how synchronization actually works.
When communicating with the server,
each client keeps track of the server time
when a given message was sent by the server
and the local time on the client when the message was received.
This allows the client to synchronize events happening on the server with its local time,
taking into account differences in system clock time and network latency.
The server reads PCM audio trunks from a named pipe.
This audio can be in a variety of formats.
Flux is the default and I've not experimented with other formats here.
I've not read a reason to.
When an audio trunk is read by the server,
it's time stamped with the server's time,
encoded in the over-the-wire protocol that subcasts users for communication
and is sent to each connected client.
Once received by the client,
the trunk is placed in a local buffer
and played at the appropriate time as determined by the ongoing clock synchronization.
If time deviations occur,
they are corrected by duplicating or removing individual samples.
More detailed description of this is available on the project page on GitHub
and there will be a link in the show notes for this.
Snapcast in theory supports any software that can help audio via a named pipe.
That being said, the two that I use most are MPD, the Music Player Demon and MPV,
both of which as well as the Snap server itself I have running on my home NAS.
MPD I use mainly for music, MPV for everything else,
for example podcasts, any streamed online content.
To control Snapcast itself, there's a variety of options.
Firstly, I've used an Android app, SnapDroid,
which is made by the developer of SnapCast,
and a third-party web interface,
SnapCast-volume-UI.
There's also a JSON RPC API for SnapServer,
and this is something I've been meaning to look into for a while,
so I would quite like some nice lightweight command line tools to control SnapServer.
So I've been using SnapCast myself for around a year now.
I started with the common and likely intended use case
of having speakers throughout my home and having SnapCast distribute audio to them.
This worked really well.
I didn't notice any audio artifacts, anything like this.
It just seemed to work really well.
A second use case I have, which SnapCast is likely not really designed for,
is streaming audio to single devices,
and in my case these are devices that don't have my full audio collection,
or maybe I want to resume listening to a podcast that I started on the device
or something like this.
And in that case, I can run the SnapServer on the machine I want to stream from,
and the SnapClient on the machine I want to stream to.
Yeah, it was an easy thing for me to implement at the time I realised I needed it.
There are probably better options to do this, but it works well enough.
It also works over, so I use a mesh VPN for a lot of the PCs I use,
and running SnapServer over that works pretty well,
so I can have my small laptop which I use for travelling and things like that
and still listen to my full audio collection on my home nuts.
So, I hope this has been a useful introduction to SnapCast.
I'll add any relevant links in the show notes,
the GitHub page and the software I mentioned.
So yeah, that's all I have for now. Have a great day.
You've been listening to HekaPublic Radio at HekaPublicRadio.org.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing
to find out how easy it really is. HekaPublic Radio was founded by the digital dog pound
and the Infonomicon Computer Club, and is part of the binary revolution at binwave.com.
If you have comments on today's show, please email the host directly,
leave a comment on the website or record a follow-up episode yourself.
Unless otherwise stated, today's show is released on the create of comments,
inclusion, share-like, free-to-life sense.
