Snapcast has been pretty rock solid for me. I will be thrilled when Badaix gets it so you can dynamically assign Snapclients to Snapservers via his Android app. It’s not a high priority item for me because I live alone, but that could change.
Anyway, I haven’t delved into the alternatives, but I haven’t had to. Snapcast has worked well for me.
FWIW, my Pi 2B was my Mopidy/Snapserver/Snapclient, but I had issues with dropouts on the Pi B clients. I switched to my Pi 3B but the problems persisted. In the end what seems to have fixed the problems was changing Wi-Fi dongles. I am still using Edimax, but the larger one. I think the smaller antennae was causing retries and saturating my wireless network. I’m also using wired data when possible. Most of my issues were with the original Pi B’s. They are single core and having them babysit the USB Wi-Fi dongle may have been part of the problem. Apparently USB2 takes up a lot of the Pi B’s CPU power.
I’ve been largely trouble-free for a month now.
I had tried the various Codex’s for Snapcast, but the ease of decoding FLAC made it better for the Pi B’s. Vorbis and PCM were both worse, Vorbis probably too complex to decode while babysitting the USB port and PCM too much bandwidth. In my experience FLAC is the Goldilocks solution, not too much CPU, not too much bandwidth, but just right.
@kraigompls69 Thanks for the info. Did you try a different sample rate? eg 44.1kHz instead of 48? Presumably that would save a little bandwidth.
I thought the Android app already lets you assign between different clients and servers. I’ve only tried it with one server, but I assumed it let you do whatever you want.
Regarding the codecs: I highly recommend to use FLAC as long as your home network doesn’t have very limited bandwidth (I hope not).
I successfully tested the Snapclient on a 400 MHz MIPS router with the ogg vorbis codec. On Android and OpenWRT the Snapclient is compiled with “Tremor”, an integer only ogg vorbis decoder, while the Raspberry (ARM) version is using libvorbis (using floating point arithmetics).
Vorbis encoding was completely killing my router (i.e. in server mode). I think that a single core raspberry will also have trouble with vorbis encoding.
I’m simply using the default codec (FLAC), which is running smoothly on all my client devices (OpenWRT router, Android, raspberry, …).
I did not try different sampling rates. A 9% reduction in bandwidth hardly seems worth the expense of resampling. Remember that 48k was chosen because it’s a difficult to conver 44.1 <–> 48. You either take a big CPU hit or you introduce artifacts (or both).
Slightly better dongles made all the difference, although I can’t say why with any certainty. My guess remains fewer dropped packets = less network traffic, which helps the whole system.
I’ll have to look at the android app a little closer. It’s good to see @BadAix here.
Thank you for Snapcast. It’s easy and effective!