snapcast

Synchronous multiroom audio player

6,143

456

6,143

View on GitHub

Top Related Projects

owntone-server

2,065

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.

owntone-server

2,065

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.

Quick Overview

Snapcast is an open-source multiroom client-server audio player. It allows you to synchronize audio playback across multiple devices on your network, creating a seamless multi-room audio experience. Snapcast supports various audio sources and can be integrated with other audio systems like MPD or Mopidy.

Pros

Synchronized audio playback across multiple devices
Low latency and high audio quality
Supports various audio sources and integrations
Cross-platform compatibility (Linux, macOS, Windows, Android)

Cons

Setup can be complex for beginners
Limited built-in audio source options
Requires a dedicated server to run
May require additional configuration for optimal performance

Getting Started

To get started with Snapcast, follow these steps:

Install the Snapcast server on your main device:
```
sudo apt-get install snapserver
```
Install Snapcast clients on your playback devices:
```
sudo apt-get install snapclient
```

Configure the server by editing /etc/snapserver.conf:

[stream]
source = pipe:///tmp/snapfifo?name=default

Start the Snapcast server:
```
sudo systemctl start snapserver
```
Connect clients to the server:
```
snapclient -h <server_ip_address>
```

Stream audio to the server using a compatible audio source or by creating a named pipe:

mplayer -ao alsa:device=hw=0.0 -quiet -slave -af resample=44100 /path/to/audio.mp3 > /tmp/snapfifo

For more detailed instructions and advanced configurations, refer to the project's GitHub repository and documentation.

Competitor Comparisons

owntone-server

2,065

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.

Pros of OwnTone

Full-featured music server with library management and streaming capabilities
Supports a wide range of audio formats and streaming protocols
Includes a web interface for easy management and playback control

Cons of OwnTone

More complex setup and configuration compared to Snapcast
Heavier resource usage due to its comprehensive feature set
Limited to audio streaming from a central server, lacking Snapcast's multi-room sync capabilities

Code Comparison

OwnTone configuration example:

<library>
  <name>My Music Library</name>
  <path>/path/to/music</path>
  <scan_interval>3600</scan_interval>
</library>

Snapcast client configuration example:

{
  "host": "snapserver.local",
  "port": 1704,
  "latency": 0
}

Both projects serve different purposes in the audio streaming ecosystem. OwnTone is a full-fledged music server with library management, while Snapcast focuses on synchronized multi-room audio playback. OwnTone is better suited for users who want a complete music server solution, whereas Snapcast excels in distributing audio across multiple devices with precise synchronization.

shairport-sync

7,220

AirPlay and AirPlay 2 audio player

Pros of Shairport-sync

Specifically designed for AirPlay audio streaming, providing native support for Apple devices
Offers high-quality audio synchronization and metadata support
Supports a wide range of audio output options, including ALSA, PulseAudio, and Jack

Cons of Shairport-sync

Limited to AirPlay protocol, lacking support for other streaming methods
Requires more setup and configuration compared to Snapcast's simpler approach
May have higher CPU usage due to real-time audio processing and synchronization

Code Comparison

Shairport-sync (configuration example):

general = {
  name = "Living Room";
  output_backend = "alsa";
  mixer_control_name = "PCM";
};

Snapcast (client configuration example):

{
  "host": "snapserver.local",
  "port": 1704,
  "latency": 0,
  "codec": "flac"
}

Both projects use different approaches to configuration. Shairport-sync uses a more traditional configuration file format, while Snapcast employs JSON for client configuration. Snapcast's approach may be more familiar to developers working with modern web technologies.

While Shairport-sync excels in AirPlay streaming and synchronization, Snapcast offers a more versatile multi-room audio solution supporting various streaming protocols. The choice between the two depends on specific use cases and device ecosystem preferences.

librespot

4,819

Open Source Spotify client library

Pros of librespot

Specifically designed for Spotify streaming, offering native support for Spotify Connect
Lightweight and efficient, focusing solely on Spotify playback
Provides a Rust API for integration into other applications

Cons of librespot

Limited to Spotify streaming only, lacking support for other audio sources
Doesn't offer multi-room synchronization capabilities out of the box
Less flexible for creating custom audio streaming setups

Code Comparison

librespot:

let (mut player, credentials) = Player::new(PlayerConfig::default(), session, None, move |_| {});
player.load(SpotifyId::from_base62("spotify:track:...").unwrap(), true, 0);
player.play();

Snapcast:

stream = streamManager->addStream("spotify:///librespot?name=Spotify&sampleformat=44100:16:2");
client = clientManager->addClient(client_socket);
client->setStream(stream);

Summary

librespot is a specialized Spotify client library, offering efficient Spotify streaming capabilities. Snapcast, on the other hand, is a multi-room audio solution that supports various audio sources, including librespot. While librespot excels in Spotify integration, Snapcast provides a more comprehensive audio distribution system with synchronization features.

MPD

2,169

Music Player Daemon

Pros of MPD

Broader audio format support, including streaming services
More extensive playlist management and database features
Longer development history and larger community

Cons of MPD

Lacks built-in multi-room synchronization
More complex setup and configuration
Requires separate client applications for user interaction

Code Comparison

MPD configuration example:

music_directory		"/var/lib/mpd/music"
playlist_directory	"/var/lib/mpd/playlists"
db_file			"/var/lib/mpd/tag_cache"
log_file		"/var/log/mpd/mpd.log"
pid_file		"/run/mpd/pid"

Snapcast client configuration example:

{
  "host": "localhost",
  "port": 1704,
  "latency": 0,
  "codec": "flac",
  "sampleformat": "48000:16:2"
}

Summary

MPD is a versatile music player daemon with extensive features for managing and playing audio content. It offers broad format support and robust playlist management but requires additional setup for multi-room audio.

Snapcast, on the other hand, specializes in synchronized multi-room audio streaming with a simpler configuration process. However, it has more limited audio format support and lacks built-in playlist management features.

The choice between MPD and Snapcast depends on specific use cases, with MPD better suited for comprehensive audio management and Snapcast excelling in multi-room synchronization scenarios.

owntone-server

2,065

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.

Pros of OwnTone

Full-featured music server with library management and streaming capabilities
Supports a wide range of audio formats and streaming protocols
Includes a web interface for easy management and playback control

Cons of OwnTone

More complex setup and configuration compared to Snapcast
Heavier resource usage due to its comprehensive feature set
Limited to audio streaming from a central server, lacking Snapcast's multi-room sync capabilities

Code Comparison

OwnTone configuration example:

<library>
  <name>My Music Library</name>
  <path>/path/to/music</path>
  <scan_interval>3600</scan_interval>
</library>

Snapcast client configuration example:

{
  "host": "snapserver.local",
  "port": 1704,
  "latency": 0
}

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Snapcast

Snapcast Snapweb-Dark

Synchronous audio player

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.
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.
One of the most generic ways to use Snapcast is in conjunction with the music player daemon (MPD) or Mopidy.

Overview

How does it work

The Snapserver reads PCM chunks from configurable stream sources:

Named pipe, e.g. /tmp/snapfifo
ALSA to capture line-in, microphone, alsa-loop (to capture audio from other players)
TCP
stdout of a process
Many more

The chunks are encoded and tagged with the local time. Supported codecs are:

PCM lossless uncompressed
FLAC lossless compressed [default]
Vorbis lossy compression
Opus lossy low-latency compression

The encoded chunks are sent via a TCP connection to the Snapclients. Each client does continuous time synchronization with the server, so that the client is always aware of the local server time. 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 dependend low level audio API (e.g. ALSA) at the appropriate time. Time deviations are corrected by playing faster/slower, which is done by removing/duplicating single samples (a sample at 48kHz has a duration of ~0.02ms).

Typically the deviation is below 0.2ms.

For more information on the binary protocol, please see the documentation.

Installation

You can either install Snapcast from a prebuilt package (recommended for new users), or build and install snapcast from source.

Install Linux packages (recommended for beginners)

Snapcast packages are available for several Linux distributions:

Nightly builds

There are debian packages of automated builds for armhf, arm64 and amd64 in Snapcast Actions - Package workflow. Download and extract the archive for your architecture and follow the debian installation instructions.

Install using Homebrew

On macOS and Linux, snapcast can be installed using Homebrew:

brew install snapcast

Installation from source

Please follow this guide to build Snapcast for

Configuration

After installation, Snapserver and Snapclient are started with the command line arguments that are configured in /etc/default/snapserver and /etc/default/snapclient. Allowed options are listed in the man pages (man snapserver, man snapclient) or by invoking the snapserver or snapclient with the -h option.

Server

The server configuration is done in /etc/snapserver.conf. Different audio sources can by configured in the [stream] section with a list of source options, e.g.:

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

Available stream sources are:

pipe: read audio from a named pipe
alsa: read audio from an alsa device
librespot: launches librespot and reads audio from stdout
airplay: launches airplay and read audio from stdout
file: read PCM audio from a file
process: launches a process and reads audio from stdout
tcp: receives audio from a TCP socket, can act as client or server
meta: read and mix audio from other stream sources

Client

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.

Available audio backends are configured using the --player command line parameter:

Backend	OS	Description	Parameters
alsa	Linux	ALSA	`buffer_time=<total buffer size [ms]>` (default 80, min 10) `fragments=<number of buffers>` (default 4, min 2)
pulse	Linux	PulseAudio	`buffer_time=<buffer size [ms]>` (default 100, min 10) `server=<PulseAudio server>` - default not-set: use the default server `property=<key>=<value>` set PA property, can be used multiple times (default `media.role=music`)
oboe	Android	Oboe, using OpenSL ES on Android 4.1 and AAudio on 8.1
opensl	Android	OpenSL ES
coreaudio	macOS	Core Audio
wasapi	Windows	Windows Audio Session API
file	All	Write audio to file	`filename=<filename>` (`<filename>` = `stdout`, `stderr`, `null` or a filename) `mode=[w

Parameters are appended to the player name, e.g. --player alsa:buffer_time=100. Use --player <name>:? to get a list of available options.
For some audio backends you can configure the PCM device using the -s or --soundcard parameter, the device is chosen by index or name. Available PCM devices can be listed with -l or --list
If you are running MPD and Shairport-sync into a soundcard that only supports 48000 sample rate, you can use --sampleformat <arg> and the snapclient will resample the audio from shairport-sync, for example, which is 44100 (i.e. --sampleformat 48000:16:*)

Test

You can test your installation by copying random data into the server's fifo file

cat /dev/urandom > /tmp/snapfifo

All connected clients should play random noise now. You might raise the client's volume with "alsamixer". It's also possible to let the server play a WAV file. Simply configure a file stream in /etc/snapserver.conf, and restart the server:

[stream]
source = file:///home/user/Musik/Some%20wave%20file.wav?name=test

When you are using a Raspberry Pi, you might have to change your audio output to the 3.5mm jack:

#The last number is the audio output with 1 being the 3.5 jack, 2 being HDMI and 0 being auto.
amixer cset numid=3 1

To setup WiFi on a Raspberry Pi, you can follow this guide

Control

Snapcast can be controlled using a JSON-RPC API over plain TCP, HTTP, or Websockets:

Set client's volume
Mute clients
Rename clients
Assign a client to a stream
Manage groups
...

WebApp

The server is shipped with Snapweb, this WebApp can be reached under http://<snapserver host>:1780.

Snapweb-Light Snapweb-Dark

Android client

There is an Android client snapdroid available in Releases and on Google Play

Snapcast for Android

Contributions

There is also an unofficial WebApp from @atoomic atoomic/snapcast-volume-ui. This app lists all clients connected to a server and allows you to control individually the volume of each client. Once installed, you can use any mobile device, laptop, desktop, or browser.

There is also an unofficial FHEM module from @unimatrix27 which integrates a Snapcast controller into the FHEM home automation system.

There is a snapcast component for Home Assistant which integrates a Snapcast controller in to the Home Assistant home automation system and a snapcast python plugin for Domoticz to integrate a Snapcast controller into the Domoticz home automation system.

For a web interface in Python, see snapcastr, based on python-snapcast. This interface controls client volume and assigns streams to groups.

Another web interface running on any device is snapcast-websockets-ui, running entirely in the browser, which needs websockify. No configuration needed; features almost all functions; still needs some tuning for the optics.

A web interface called HydraPlay integrates Snapcast and multiple Mopidy instances. It is JavaScript based and uses Angular 7. A Snapcast web socket proxy server is needed to connect Snapcast to HydraPlay over web sockets.

For Windows, there's Snap.Net, a control client and player. It runs in the tray and lets you adjust client volumes with just a few clicks. The player simplifies setting up snapclient to play your music through multiple Windows sound devices simultaneously: pc speakers, hdmi audio, any usb audio devices you may have, etc. Snap.Net also runs on Android, and has limited support for iOS.

Setup of audio players/server

Snapcast can be used with a number of different audio players and servers, and so it can be integrated into your favorite audio-player solution and make it synced-multiroom capable. The only requirement is that the player's audio can be redirected into the Snapserver's fifo /tmp/snapfifo. In the following configuration hints for MPD and Mopidy are given, which are base of other audio player solutions, like Volumio or RuneAudio (both MPD) or Pi MusicBox (Mopidy).

The goal is to build the following chain:

audio player software -> snapfifo -> snapserver -> network -> snapclient -> alsa

This guide shows how to configure different players/audio sources to redirect their audio signal into the Snapserver's fifo:

Roadmap

Unordered list of features that should make it into the v1.0

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot