Snapcast

Synchronized multi-room audio streaming player

Media Servers ★ 7.9k stars Medium setup GPL-3.0

Snapcast is a multi-room audio streaming system that keeps playback perfectly synchronized across many clients. It is commonly paired with Mopidy or MPD to build a self-hosted whole-home audio setup.

Key features

  • Synchronized multi-room audio
  • Low latency
  • Works with MPD and Mopidy
  • Lightweight clients

Pros & cons

Strengths

  • Excellent sync accuracy
  • Runs on tiny devices

Trade-offs

  • No standalone library
  • Needs a separate music source

Snapcast replaces

Last reviewed Sep 13, 2026 · 942 words

Snapcast plays nothing on its own. It is a pipe: a server takes one audio stream, timestamps it, and pushes it to any number of clients that play it at the same instant, close enough that walking between rooms produces no echo. The music has to come from somewhere else, usually MPD, Mopidy, librespot for Spotify Connect, or Music Assistant, and the clients are whatever cheap board you put next to a speaker. Understand that division of labour and Snapcast is the cheapest, most accurate multi-room system you can build; expect it to be a Sonos app and you will be confused within the hour.

Server, sources, and the fifo trick

snapserver reads from one or more sources declared in /etc/snapserver.conf. The simplest is a named pipe, and it is how MPD and Mopidy plug in without either knowing Snapcast exists:

[stream]
source = pipe:///tmp/snapfifo?name=Default&sampleformat=48000:16:2

Point MPD at that pipe and you are done:

audio_output {
    type     "fifo"
    name     "snapcast"
    path     "/tmp/snapfifo"
    format   "48000:16:2"
    mixer_type "software"
}

Other source types cover most of what a household wants: librespot:// runs a Spotify Connect endpoint inside the server, airplay:// wraps shairport-sync so phones can AirPlay to the whole house, tcp:// accepts raw PCM from anything that can write to a socket, process:// spawns a command and reads its stdout, and meta:// merges several sources with priority so a Spotify session interrupts the radio and hands back when it stops. Multiple streams can run at once, and each client group picks which one it listens to.

Ports are 1704 for client audio, 1705 for the JSON-RPC control API, and 1780 for the built-in web UI, Snapweb, which is where you drag clients between groups and set per-client volume and latency.

Why the sync actually works

The server slices audio into chunks and stamps each with a play time about a second in the future; clients keep their clock aligned to the server over the control connection and hold each chunk in a buffer until its moment. The default buffer is 1,000 ms, which is why pause and volume feel slightly laggy compared with a local player and why the project describes itself as multi-room rather than low-latency. In return, a Pi Zero and a laptop and an Android phone all land within a few milliseconds of each other, and per-client latency offsets in Snapweb correct for the extra delay a Bluetooth speaker or a TV's HDMI path introduces. It is the sync accuracy that people who have tried the DIY alternatives come here for.

Clients: anything with a DAC and a network

snapclient is a small C++ program that runs on Linux, macOS, Windows, and Android (Snapdroid on the Play Store and F-Droid), and community ports run it on an ESP32 with an I2S DAC for about $10 of parts per room. The classic build is a Raspberry Pi Zero 2 W with a $5 DAC hat or a USB audio dongle feeding a pair of powered speakers, drawing under 1 W. Debian and Ubuntu package snapclient and snapserver directly, so apt install is the whole install on a Pi; Docker images exist for the server but the client wants direct access to the sound card, so keep it on bare metal. A client is stateless; if a room loses power, it reconnects and rejoins its group on boot.

Where the library and the remote come from

Because Snapcast has no music library, you pair it. MPD is the lean choice, with a dozen good phone remotes and a local file library. Mopidy adds streaming service extensions and a web front end, and its GStreamer output writes to the same fifo. For a household that already runs Home Assistant, the integration exposes every Snapcast client as a media player entity with volume and group controls, and Music Assistant can run a Snapcast server itself so a single app handles library, streaming services, and room selection. If you want your own Spotify-like library server with a web player, Navidrome is the better front end, though it does not output to Snapcast directly and needs a bridge like MPD or Music Assistant in between.

Versus buying speakers

Sonos gives you the app, the speakers, the setup wizard, and a bill of about $200 per room at last check, plus a dependency on a cloud account and firmware decisions you do not control. Snapcast plus a Pi and a used pair of powered bookshelf speakers runs about $60 to $80 per room, sounds as good as the speakers you chose, and works offline forever. The cost is that you assemble it, you maintain a second service for the library, and guests cannot cast to it without you setting up AirPlay or Spotify Connect sources. For a tinkerer with 3 or more rooms it is a clear win; for one room, plug the speakers into the source and skip Snapcast entirely.

What I'd do

snapserver on the same box as MPD with a fifo source, a librespot source layered in via meta so Spotify takes over when someone starts it, and a Pi Zero 2 W with a cheap DAC in each room running the Debian snapclient package. Manage groups from Snapweb, and expose the clients through Home Assistant if you already run it. Add Music Assistant later if you want one app for everything; start with MPD because it is the fewest moving parts between a folder of FLAC and every room in the house.

Compare Snapcast

5 head-to-head comparisons.

Similar media servers apps