7c8efd2228
- MCP server with stdio transport for local use - Search episodes, transcripts, hosts, and series - 4,511 episodes with metadata and transcripts - Data loader with in-memory JSON storage 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
120 lines
6.0 KiB
Plaintext
120 lines
6.0 KiB
Plaintext
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.
|