Interesting. So are you saying that even in a single-room playback scenario, the DAC is not the clock master and it is PLLing to the network audio data rate? That is, it is pushing data to the DAC versus the DAC pulling it?
The two most important locations are both on fiber with sub-millisecond ping times to major backbones, but the others include FTTN cable and Starlink which are much higher latency. The audio files are so small by modern standards we could easily keep a server in each location along with rsync or some other file synchronization if it is absolutely necessary. The remote server is really needed for just the ARC clients. Also, we would only want to pay for Roon once - we are just a family of three after all…
I don’t think @anon77144803 says this at all. Roon uses RAAT, and the DAC always controls timing*, but it wasn’t designed for the scenario you describe. RAAT is unforgiving when there’s high latency or any network glitch for that matter.
That’s why we have Roon ARC for playback over the Internet. Whilst you may get things working, you may experience dropouts or clicks, as much of the network you describe is entirely out of your control. But there’s only one way to find out.
*Grouped zones uses a different approach, with one DAC controlling timing and Roon handling synchronization.
So perhaps a good compromise might be to have a Roon server at each location for a low latency server to DAC connection, but the servers all connect to a single library fileserver which could be a higher latency connection via the internet / VPN. Presumably the Roon Server is willing to do more buffering on the filesystem / pre-transcoding side of things where latency is not a problem?
Does anyone know off hand if each Roon Server needs to be licensed separately or are there provisions for same-user multiple location setups like this?
No not at all. I was saying that if you plan to use Roon via vpn it may not work particular well due to the low tolerance of latency RAAT requires. Many who try experience drop outs regularly because of it. The DAC owns the clock in Roon but that has nothing to do with this. If it works in your setup fine but it doesn’t for a lot who try.
There are a few of us running dual server configurations.
They don’t share a database, so even though you can share ‘local’ music files - as well as streaming files - they don’t automatically share data like play counts and playlists.
I can find the relevant discussion if you want to better understand the options.
You could do that but would need a license for each one to keep them all active. You can transfer license from one to another but not have it active on all three at same time. You can have more than one license on your account though.
Roon has small buffers and will likely still have issues with a remote file server if can’t be pulled fast enough. Many experience issues with streaming from Tidal or Qobuz if the data rate pulled from source location can’t keep up to the demand.
You might want to look at PlexAMP. Or, do some packet captures. It isn’t all that complicated what Roon is doing but once you see it… you’ll probably not want that traffic over any kind of “WAN” connection unless you own the facilities.
The one thing I don’t see said accurately in this thread so I’ll say it now. Roon is designed to work within a single broadcast domain. Broadcast domains are usually a L2 thing. This is why, even if you proxy the multicast discovery, people still have issues. So, unless you’re willing to build a flat L2 network between your locations (using a tunnel or otherwise) expect issues. And even then, since Roon expects that L2 network to live within a single ethernet wire segment and now you’re propagation delay is going to a LEO satellite, expect other problems like plenty of random playback stops.
There is no easy answer here. I proposed something many years back (lookup ROCK-R). Someone else, I forget who, posted a simpler idea which would also work. But, there isn’t a supported solution here.
Can you make it work? Anything is possible.
Now ARC? ARC has little to do with what you describe. It’s designed to let remote Android and iOS devices come back to your Core to stream while you’re away. But, it’s not Roon. It doesn’t support endpoints. Will it work for a single user on headphones, USB-C DAC, or out to a BT speaker of an Android or iOS device in, say, a dorm? Yes, in fact that’s an excellent use case. But, it’s not Roon.
Thanks for the tips. I will also check out PlexAMP. I’ve been a Plex user for a number of years, and that has worked well across the same network I have described here. I do have some higher end audio equipment, mostly self-made, which along with a recent home theater receiver purchase that supports Roon that got me interested in the Roon world. I have a large lossless music collection back from CD jukebox / digital audio control software that I did in the later 90’s, so it would be nice to have a good interface with which to revisit that and be able to listen to while on the road.
I am somewhat surprised to find that it is the networking side of things that we are doing that is somewhat antithetical to having a Roon server. I’m sure I can get the UDP Proxy working on our network, but even then, it sounds like there can be playback issues due to minimal-latency buffering. I don’t want to pay for multiple server instances on principle alone since we are effectively a single user.
