Synchronous multi room audio

[BadAix]

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.

[max]

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.

[skidoo]

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?

[skidoo]

Forgot to post config. Perhaps usefull for someone.

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
}

Tested with FFmpeg 2.7.2 and MPD 0.19.10 - listen to stream with VLC ( rtp://multicastip:port ). Have fun.

[BadAix]

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?

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.html

Multicast 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 ...

and posted on superuser.com: http://superuser.com/questions/730288/w ... o-wireless

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...

or here http://superuser.com/questions/695813/w ... cast-speed

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...

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.
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.

[skidoo]

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

[utanman]

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.

[skidoo]

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.

[max]

[*]There is not native MPD plugin for Snapcast. Changing volume and muting is delayed.

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.

[skidoo]

MPD with synchronous multiroom and multiple zones? YES!