It is not a player, and sync correction happens at sample granularity

It is not a player, it is a synchroniser for your players

The second paragraph of the README is the one that decides whether this project is for you, and it is a disclaimer.

Snapcast is a multiroom client-server audio player where all clients are time synchronized with the server to play perfectly synced audio. It's not a standalone player, but an extension that turns your existing audio player into a Sonos-like multiroom solution.

So the split is explicit. You keep whatever decodes your files and drives your sound card. Snapcast takes the audio that player produces, and distributes it to other rooms in step.

The rest of that paragraph describes what makes it more than a relay: audio is captured by the server and routed to the connected clients, several players can feed audio to the server in parallel, and clients can be grouped to play the same audio stream.

That grouping is the feature. Once clients can be put in groups, one machine can hold a party without every speaker playing whatever the last thing was.

And the README names the most generic use immediately: in conjunction with the music player daemon, MPD, or Mopidy. Both are daemons that can write PCM to a pipe, which is exactly the interface Snapcast wants.

Drift is corrected by removing or duplicating single samples

The How does it work section explains the synchronisation in a way that answers the obvious question about how a networked audio system stays aligned.

The server reads PCM chunks from configurable stream sources. The chunks are encoded and tagged with the local time, then sent to the clients over a TCP connection. Each client does continuous time synchronisation with the server, so it always knows the local server time.

Then the client-side mechanism. Every received chunk is first decoded and added to the client's chunk buffer. Knowing the server's time, the chunk is played out using a system dependent low level audio API at the appropriate time.

And the correction itself: time deviations are corrected by playing faster or slower, which is done by removing or duplicating single samples.

That last clause is the whole engineering idea. A sample at 48kHz has a duration of about 0.02 milliseconds, so dropping or repeating one sample is a very small rate adjustment.

The figure the README gives for the result is that the deviation is typically below 0.2 milliseconds. For a comparison, that is a small fraction of the buffer sizes the client backends default to.

FLAC is the default, and it is the expensive one

The codec list is four items and the default is marked in the second position.

PCM, lossless and uncompressed. FLAC, lossless compressed, marked as the default. Vorbis, lossy compression. Opus, lossy low-latency compression.

So the default is the lossless compressed option rather than the lossless raw one, which is a sensible default on a network. Everything in the file is sent over TCP to the clients, so the codec choice is a bandwidth decision before it is a fidelity one.

The pipeline around it is the same regardless. The server reads PCM chunks from a stream source, encodes them, tags them with the local time, and the clients decode each chunk back before playing it through a low level audio API.

That tag is what makes the whole scheme work. Because every chunk carries the server's clock reading, a client that joins late, or whose buffer underruns and refills, can work out where it should be playing without renegotiating with the server.

The README points at a separate document for the details: the binary protocol is written up in doc/binary_protocol.md, which is where anyone implementing a client in another language would start.

Ten stream sources, and three of them just launch a process

The server reads from sources listed in the [stream] section of /etc/snapserver.conf, and the example given shows the shape of a line:

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

A scheme, a path, and query parameters carrying a display name, the sample format as rate, bits and channels, and the codec.

There are ten source types available. pipe reads a named pipe. alsa reads an ALSA device, which is also how you capture line-in, a microphone, or an alsa-loop so one player can feed another. file reads PCM from a file. tcp receives audio from a socket and can act as either client or server.

Then three that share a shape. process launches a process and reads audio from its stdout. librespot does the same with a Spotify Connect server. airplay does the same with an AirPlay receiver.

Which leaves pipewire for direct capture from PipeWire, jack for receiving from a Jack server, and meta, which reads and mixes audio from other stream sources. Meta is the one that turns a multiroom system into a mixer, and the README links doc/configuration.md for details.

Eight player backends, and the table misspells SDL2

The client table is the longest thing in the README and it is a list of operating systems rather than a list of features.

The rationale comes first: the client will use as audio backend the system's low level audio API to have the best possible control and most precise timing to achieve perfectly synced playback. Backends are chosen with the --player command line parameter.

Then one row per platform. alsa on Linux, pulse on Linux, oboe and opensl on Android, coreaudio on macOS, wasapi on Windows, sdl2 on all systems described as SDL2 Audio, a fallback that assumes constant latency, and file on all systems, which writes the audio to stdout, stderr, null or a named file in either write or append mode.

Two rows are worth reading closely. oboe is described as using OpenSL ES on Android 4.1 and AAudio on 8.1, which means the backend picks the API by OS level rather than requiring a choice. And pulse takes a property parameter that defaults to media.role=music, so the client declares its role to PulseAudio rather than being treated as a generic stream.

Parameters are appended to the player name with a colon, for example --player alsa:buffer_time=100, and --player <name>:? lists the available options.

Configuration lives in two files, and one of them is a default init script

The configuration section is short because the shape is conventional, and reading it tells you where an operator actually edits things.

Server options go in /etc/snapserver.conf. Command line arguments for the two daemons go in /etc/default/snapserver and /etc/default/snapclient.

That second pair is the Debian and Ubuntu convention for service arguments, so on another distribution those defaults move.

For the options themselves it points at the man pages, man snapserver and man snapclient, or at the -h option on either binary. That is a deliberate choice to keep the README short, and it is the right one for a tool with this many backends and source types.

Two parameters are called out because they solve problems that are otherwise confusing. The -s or --soundcard parameter picks a PCM device by index or name, and -l lists the available ones. And --sampleformat handles the case where a sound card only supports one rate, with the example being a client resampling 44100 audio from Shairport-sync up to a card that only does 48000.

The default branch is develop, and the newest release is from March 2026

Two metadata facts and one repository layout observation, and together they tell you what kind of project this is.

The default branch is develop, not master. Combined with the release list, that is a project that develops on a branch and releases from it, so a plain clone is not a released version.

The three newest releases are v0.35.0 from 2026-03-10, v0.34.0 from 2025-10-03 and v0.33.0 from 2025-09-24. The last push to develop was on 2026-10-28, so the branch is several months ahead of the last tag.

The repository layout has no src directory. The code is split into client/, server/, common/, control/, extras/, cmake/ and test/, which matches the architecture the README describes: a server, a client, the code they share, and a control protocol in its own directory.

Three root files are worth naming because they are unusual. TODO.md and changelog.md sit beside README.md, so the project tracks work in progress and history as separate documents. And Doxyfile is there for generated API documentation.

Then two files with a leading underscore, _config.yml and _CMakePresets.json.

Editorial conclusion

Take Snapcast when you already run a daemon that can write PCM to a pipe, such as MPD or Mopidy, and you want several rooms playing the same stream in step without replacing your audio hardware. Leave it if you want a player that owns the decode, because the README says plainly that it is not a standalone player but an extension that turns your existing one into a Sonos-like multiroom system. Verify three things. Test the installation end to end, as the README's Test section describes. Check which backend your machine actually has, because the buffer defaults differ per backend and ALSA starts at 80 milliseconds while PulseAudio starts at 100. And settle the codec, because FLAC is the default: it is lossless compressed, so it costs less bandwidth than uncompressed PCM and more than either lossy option.

Frequently asked questions

Official sources

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