Snapcast: turning an existing audio player into a synchronised multiroom system

Snapcast is a transport layer, not a music player

The README is explicit that Snapcast "is not a standalone player, but an extension that turns your existing audio player into a Sonos-like multiroom solution." That sentence defines both the audience and the boundary. Snapcast has no library, no queue, no search and no metadata browsing. It reads PCM chunks from a stream source, encodes them, tags them with the server's local time, and ships them over TCP to clients that decode and play them at the right moment.

The people who get value from this are running something that already produces audio: MPD, Mopidy, a line-in feed, a process writing to stdout. They have more than one room, and they want those rooms in phase. If you are looking for a self-contained appliance that indexes your files and streams to speakers, Snapcast is the wrong layer of the stack, and pairing it with a player is the work you would have to do yourself.

How the server, the codec and the client clock fit together

The server reads from configurable sources: a named pipe such as /tmp/snapfifo, ALSA capture, TCP, the stdout of a process, and several others documented separately. Each chunk is encoded with one of four codecs. PCM is lossless and uncompressed, FLAC is lossless and compressed and is the default, Vorbis is lossy, and Opus is described as lossy low-latency. The choice is a trade-off between bandwidth and CPU on both ends, and the README does not give figures for either.

Clients hold a TCP connection and continuously synchronise their clock with the server, so each client knows the server's time locally. A received chunk is decoded and placed in a buffer; the client then plays it through a system-level audio API at the computed moment. Drift is corrected by playing slightly faster or slower, implemented by dropping or duplicating individual samples. The README notes that at 48 kHz one sample lasts roughly 0.02 ms, and that typical deviation stays below 0.2 ms. That correction method is why sample-level timing matters more here than in ordinary streaming: the sync is achieved by editing the audio, not by buffering more of it.

The binary protocol has its own document in doc/binary_protocol.md, which is where you would look if you intend to write a client rather than use one.

Installing Snapcast and defining your first stream source

The README recommends a prebuilt package for new users and lists packages for Debian, OpenWrt, Alpine Linux, Archlinux and Void Linux, each pointing at a section of doc/install.md. On macOS and Linux, Homebrew is the other packaged route:

brew install snapcast

Building from source is a separate guide in doc/build.md, with sections for Linux, FreeBSD, macOS, Android, OpenWrt, Buildroot, Raspberry Pi, webOS and Windows. Cross-compilation targets are listed, so a Raspberry Pi client is a documented path rather than a workaround.

After installation, the README states that Snapserver and Snapclient are started with command line arguments configured in /etc/default/snapserver and /etc/default/snapclient. Server configuration lives in /etc/snapserver.conf, and sources are declared as a list inside the [stream] section. The README gives this example:

[stream]
source = pipe:///tmp/snapfifo?name=Radio&sampleformat=48000:16:2&codec=flac
source = file:///home/user/Musik/Some%20wave%20file.wav?name=File

Each source carries a name, a sample format written as rate:bits:channels, and a codec. The file source shows that URL-encoded spaces are expected in the path. Clients pick a backend with --player, and the README shows parameters appended after a colon, for example --player alsa:buffer_time=100. Running --player <name>:? lists the options a backend accepts, and -l or --list enumerates available PCM devices, with -s or --soundcard selecting one by index or name.

Where Snapcast breaks down or is the wrong tool

The sync mechanism is also its fragility. Because the client corrects drift by dropping and duplicating samples, any client whose buffer cannot keep up is not merely late, it is audibly edited. The README documents buffer tuning per backend: alsa defaults to buffer_time=80 ms with a minimum of 10 and fragments defaulting to 4 with a minimum of 2, while pulse defaults to buffer_time=100 ms with the same minimum. Those minimums are the floor the project itself sets, and pushing toward them trades stability for latency.

A second limitation is that the server does not invent audio. If your player stops writing to the pipe, the stream has nothing to carry. The README's own framing, that Snapcast extends an existing player, means every failure of that player is a failure of the multiroom system, and Snapcast has no role in diagnosing it.

Finally, client support is uneven by design. The backend table lists alsa and pulse for Linux, oboe and opensl for Android, coreaudio for macOS, wasapi for Windows, and sld2 for SDL2 Audio, described as being for LG webOS TVs. There is no single portable backend, so a mixed-OS household is running different code paths in each room, and the README does not claim identical behaviour across them.

Snapcast versus Squeezelite, LMS and Sonos

The comparison people search for is against Squeezelite and LMS, and the architectural difference is the point. Squeezelite is a player endpoint for a Logitech Media Server ecosystem, where the server owns the library, the queue and the streaming format. Snapcast owns none of that. It captures PCM that something else produced. If you already run LMS, adding Snapcast means inserting a capture and distribution stage that LMS does not know about; if you want one system that indexes and plays, LMS or Music Assistant is the layer Snapcast deliberately leaves out. Snapcast and LMS are not competing for the same job, and treating them as alternatives usually means the real question is which player feeds the pipe.

Sonos is the comparison the README invites with its own phrasing. The difference is that Sonos is a closed stack of hardware and software, while Snapcast is a GPL-3.0 server and client that runs on hardware you choose, including Raspberry Pi and Android devices. That freedom costs you the setup work: you supply the player, the sample format, the codec choice and the buffer settings.

Maintenance, licensing and what upgrading involves

The repository is not archived, and the last push was on 2026-06-27. The most recent release listed is v0.35.0 on 2026-03-10, preceded by v0.34.0 on 2025-10-03 and v0.33.0 on 2025-09-24. The release cadence visible here is irregular rather than monthly, and the default branch is develop, so anyone building from source is tracking a development branch rather than a release tag. The changelog.md at the repository root is where release-to-release changes are recorded, and the README does not document a rollback procedure for a bad upgrade.

Snapcast is licensed GPL-3.0. That matters if you plan to redistribute a modified server or client, or to ship a client inside a product: the licence is a copyleft licence, and the repository includes client/, server/, common/ and control/ as separate top-level directories, which is the structure you would need to inspect before deciding how a derivative would be organised. This is a description of the licence identifier, not legal advice; read LICENSE and take your own counsel.

Editorial conclusion

Adopt Snapcast when you already run a player such as MPD or Mopidy and want the same audio in several rooms without buying Sonos hardware; skip it if you want one binary that also browses and queues music, because Snapcast only captures and distributes PCM. Before committing, verify the sample format your source emits against your client's audio backend, and test the player backend on the actual hardware, since the README lists alsa, pulse, oboe, opensl, coreaudio, wasapi, sld2 and file as separate backends rather than one portable path.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. snapcast/snapcast on GitHub