I’m a big Roon fan. My current setup is a NAS at home with a spare laptop doing roon server duty. It works great. But I split my time between two geographies about half and half, and both the NAS and laptop are being stretched thin and need to be replaced. I use VPN setups to get roon access from wherever I am back to my home setup - but I find it (a) flaky and (b) instead of pulling data from point A to point B I’m pulling data from point A through a proxy to point B. It seems insane to still have hardware at home for this sort of thing.
I have fiber everywhere for Internet, so speed in theory isn’t a problem. Even Quad DSD (12 Mbps) and DXD (16 Mbps) should work.
I searched through the forums here but couldn’t find anything pop on the usual keywords (Azure, AWS, etc.).
Has anybody tried this? If I can get this to work via Hamachi (for example) from wherever I happen to be hanging out, it should work twice as well from a real data center - instead of my house.
The key to getting it to work would be the networking. Both locations and the virtual network in the cloud would have to be all on the same subnet and bridged togethor. Once you have that solved I see no reason you couldn’t put Roon core up on a VM in Azure or AWS.
understood. i do it today with hamachi (but it’s flaky). wondering if anybody does this “ferrealz” - if the connections can really ‘hold’ between the cloud core and the local client. or maybe i just have to be the guinea pig…
Curious why you believe they’d all need to be same network.
Home net (private address space) > AWS VPC < Net 2 (different private address space).
A router in the AWS VPC should be able to handle getting things to see Roon Core, no? Maybe it’s a requirement of Core, but I haven’t seen that personally.
This is a really cool question. Maybe come up with a music/roon optimized Windows or Linux AMI, layer a ROCK install over it, and off you go to the masses!
Roon core uses broadcast traffic to find playback endpoints.
While not running the core in the cloud, I did have a roon core virtual machine running in a home lab vmware data center. The rig did not run reliably due to network connectivity issues. As soon as I put physical hardware in lieu of the vm at essentially the same point in the network but outside the vmware switching environment things worked well. My issue had to do with the controller staying connected to the core. My network runs fast and is generally rock solid. I’d be thrilled to hear that someone got the routing right to deploy the core in the cloud, but even then, I suspect that network latency issues will become a problem. Good luck!
You said the magic word: “routing”.
As long as Roon keeps using broadcasts for discovery and such, nice for the general public and ease of use (it also kills a lot of support issues based on performance barriers), no routing can be involved.
I’d love to see an optional advanced option to set things to manual (Remote, here is your Core, Core, here are your Bridges), allow routing (are those things like RAAT really not routable because of their design?) and let us deal with low bandwidth/high latencies results (ever used Roon using a crap WiFi link between a Core and a Bridge?)!
Then AWS and friends, VPNs and such will be possible.
We find the concept very desirable, but we may not like the end result…
I still say that we should have the choice, as an option, with a possible automatic resampling to lower rates. If it breaks our music, we keep the pieces.
If you have Gb internet at both your locations why not put in hardware and do a permanent bridged VPN between your locations and keep your NAS and Roon core at one location and have the extra endpoints you need at your second location. This could be achieved with regular consumer routers and OpenVPN TAP.
That might work if using OpenVPN to attach a node to a remote network but I suspect it gets a bit hairy if you want to use OpenVPN to bridge a pair of networks. I run OpenVPN to bridge a pair of networks and found that while OpenVPN handled routing properly ROON controllers on one side couldn’t see a Core on the other because the two networks, while connected, had distinct address spaces, i.e., they were on different subnets.
Would that it were easier!
2 networks defeats the point of bridging the networks for broadcast traffic. You would bridge with TAP and use the same network address space on both ends. Care would need to be taken when defining the static IP gateways on both sides and the dhcp server ip address scope on both ends to avoid collisions.
One other thing about Roon in the Cloud/AWS, is it could get expensive quickly. I’d forgotten that AWS charges for egress bandwidth, which is most of what your streaming will be. The cost of the permanent infrastructure would be fairly low, but bandwidth charges not so much. Would be so nice to get all the FLAC up to S3 or Glacier as well…
Well, Glacier in particular is set up with an emphasis on archiving and infrequent and very slow retrieval.
I wonder if they key here might be to support Plex as a service. Plex servers can serve lossless and high def files from anywhere as direct play. SOnos has a plug-in for this in beta right now. Plex libraries can be hosted anywhere and accessed anywhere there is a client. A future Roon server with a Plex service could access the file and library services of Plex.