Hi,
I want to introduce SnapCast (https://github.com/badaix/snapcast), a client/server system where the server forwards audio to all connected clients.
I started to develop SnapCast because I wanted to have my MPD audio stream in more than one room. I read about people unsuccessfully trying to achieve this using PulseAudio or Icecast. In the SnapCast setup, MPD is playing the audio into a pipe output, while the SnapServer is reading from the pipe and forwards the audio stream (with time information added) to all connected SnapClients (running preferably on a raspberry pi).
The SnapClients are continuously synchronizing their time against the SnapServer, enabling them to play the audio stream in chorus.
Synchronous multi room audio
Re: Synchronous multi room audio
Why not implement this is an output plugin inside MPD? There are so many unsolvable problems with the pipe output, which can be solved easily by running it as a full-featured plugin.
Re: Synchronous multi room audio
TCP for transferring audio to many recipients in a LAN seems terribly wrong (at least to me). Why not use multicast RTP? The corresponding function is in ffmpeg already. Or have I missed something important?
Re: Synchronous multi room audio
Forgot to post config. Perhaps usefull for someone.
Tested with FFmpeg 2.7.2 and MPD 0.19.10 - listen to stream with VLC ( rtp://multicastip:port ). Have fun.
Code: Select all
audio_output {
type "pipe"
name "Multicast RTP"
command "ffmpeg -nostats -re -f s16le -ac 2 -i pipe:0 -acodec pcm_s16be -f rtp rtp://239.9.3.2:1111"
format "44100:16:2"
# re read input at native frame rate
# f = s16le input from MPD's pipe is little endian PCM
# ac = 2 number of audio channels, stereo
# acodec = pcm_s16be output to stream is big (!) endian PCM
# f = rtp output from ffmpeg is RTP
# rtp://ip:port RFC2365 "Administratively Scoped IP Multicast"
# IP range 239.0.0.0/8 and port > 1024
}
Re: Synchronous multi room audio
Agree, it seems wrong. But it also seems that there are a couple of drawbacks with multicast over WiFi, as described in this paper: https://tools.ietf.org/id/draft-mcbride ... nt-00.htmlskidoo wrote:TCP for transferring audio to many recipients in a LAN seems terribly wrong (at least to me). Why not use multicast RTP? The corresponding function is in ffmpeg already. Or have I missed something important?
and posted on superuser.com: http://superuser.com/questions/730288/w ... o-wirelessMulticast over wifi has been used to low levels of success, usually to a point of being so negative that multicast over wifi is not allowed ... [snip] ... To make make multicast over wifi work successfully they often need to modify the multicast to instead be sent as unicast in order for it to successfully transmit with useable quality ...
or here http://superuser.com/questions/695813/w ... cast-speedsuperuser.com wrote:Why do some WiFi routers block multicast packets going from wired to wireless?
It's usually due to bugs in the Wi-Fi home gateway routers (APs), or sometimes in the wireless client chipsets/drivers/software...
When streaming CD quality audio, you will need 1.4 Mbit/s per connected client. Because SnapCast is using FLAC, it's roughly 0.8 Mbit/s per client. In a typical home setup you might connect three or four (3.2 Mbit) or maybe at most up to ten (8 Mbit) clients, which can be easily handled by (wireless-) LANs.superuser.com wrote:WiFi UDP unicast vs. multicast speed
Any kind of multicast/broadcast over Wi-Fi is going to be slow because Wi-Fi requires multicasts and broadcasts to be sent at a kind of "lowest common denominator" transmission speed...
Because of the unicast TCP transfer, it is also guaranteed that there are no packet losses or out of order packets that would result in degraded audio quality.
I'm sure that the ffmpeg way is good for streaming the audio on different clients, but they will not play in sync.
Re: Synchronous multi room audio
Multicast is a challenge to your local wired network. Dump unmanaged switches make no difference between multicast and broadcast pakets .
Wi-Fi makes it worse...
I'm curious: synchronous playback by the Snapcast protocol despite of different methods (ALSA, pulses, JACK) and audio hardware? Tell us more

I'm curious: synchronous playback by the Snapcast protocol despite of different methods (ALSA, pulses, JACK) and audio hardware? Tell us more

Re: Synchronous multi room audio
I use Snapcast in my home witht he described method in Mpd. I like it and I am happ with it. I hope that @ BadAix keeps developing it. This is the easiest setup I have found to be producing decent (and mostly consistent) results with synced audio.
Re: Synchronous multi room audio
Yes it works but it is not perfect (yet
)

- Snapcast plays music with "hickups" until all clocks are in sync.
- There is not native MPD plugin for Snapcast. Changing volume and muting is delayed.
- MPD does not support multiple audio outputs (yet). Therefore no support for Snapcast zones.
Re: Synchronous multi room audio
That problem is based on the bottom-most architecture decision of Snapcast, and I pointed that out 3 years ago in this thread. This Snapcast problem cannot be solved.
This should really be a MPD core feature, without needing third-party software such as Snapcast.
Re: Synchronous multi room audio
MPD with synchronous multiroom and multiple zones? YES!