If Tailscale is built in to Roon on the server and the need to have the Tailscale app on your phone to establish the VPN, is there an actual need for users to use Arc other than downloading your own content?
It’s known that using VPNs can give use of your Roon server remotely. Why not build in a download function into the Roon (remote) app.
Some users may find this new approach trickier to accomplish over port forwarding, although overcomes ISP restrictions.
I imagine a good number of users who use Arc do so via Tidal or Qobuz only, so downloads not possible.
I have a UniFi network and a VPN setup on it.
On my test machine I have Roon EA 1456 and subsequent EA Roon (remote🙄) on my phone. With an adequate mobile signal I get great playback via the Roon app. Albeit with greater data use. So playback via a mobile data plan reduction in quality/data is also required.
Is the direction Roon is exploring? Makes sense to me to do so. Others platforms have achieved this.
My experience using Wireguard built into my router (and built on the same technology as Tailscale) is that Roon (Windows desktop and Android Remote) did work on the Wireguard VPN being able to connect to the Roon Server without issue but there was a long delay (15-20 minutes) between starting the Roon App(lication) and the Roon Server being able to see the Roon Endpoints associated with that Roon application instance - presumably because the VPN does not fully support multi-cast traffic.
[Of course, whilst I was in the Orkneys as I was at the time, I couldn’t resist starting to play some music on my daughters PC when she turned it on back in Cambridgeshire because that endpoint was discovered immediately and was visible in the Roon application as soon as it started up - she was not impressed.]
By contrast, on the same router, I set up an OpenVPN TAP interface VPN (layer 2) which does support multi-cast traffic over the network and using that did allow my laptop (running the OpenVPN client) to run Roon and connect to the server and provide endpoints immediately. The problem with the OpenVPN TAP interface is that it is not supported by OpenVPN for Android and thus, as a solution it is not available for Android phones and tablets (IOS devices may or may not have the same issue - I don’t know).
TUN interface OpenVPN VPNs have the same issue as Tailscale and Wireguard. They do not support layer 2 multicast traffic and so endpoint discovery over the VPN will take a long time (if it works at all).
This would not be enough. As you know, RAAT depends on a low-latency network and a mobile phone on 5G/4G is the opposite of that in the general case. Yes it may work with a good mobile signal or on a foreign LAN but as you also know people even struggle to make RAAT work reliably on their own LANs sometimes. Total support nightmare.
In the end a solution would amount to unifying the whole apps either by adding the mobile network stack to the Roon mobile app or by adding missing features like Focus to ARC (edit: and RAAT). Which wouldn’t necessarily be a bad thing and may happen anyway, but it’s more involved than just adding downloads to Roon mobile.
But it will appear that Roon 2.1 will now need to be a 3 app setup for users with ISP restrictions. 2 apps for Roon/Arc, in my view is bad enough.
Are you saying Arc doesn’t use RAAT
I’m aware the use of VPN was discussed upon the EA of Arc. It wasn’t implemented though.
Being implemented now, is just as an add on. Unless 2.1 is a full new build and all existing bugs fixed , it’s likely to cause further support posts in a vast numbers, and hopefully not, but cause bugs elsewhere.
It is only my view, but the way forward isn’t this.
Option to have “use RAAT when on LAN” & “don’t use RAAT when VPN detected” maybe essential.
However, I still feel a concern over weak mobile connections with a VPN for Arc.
Currently I’m seeing on EA1456, even when Arc is set to original format, yet I’m getting MP3 from Qobuz
Maybe internally on a low level, I don’t know, but certainly there are layers that implement larger on-device buffers to make ARC cope better with variable network speed/latency. When Roon explained why ARC was a separate app at least for the time being, I think one of the reasons given was that the network stack is necessarily very different for the mobile use scenario
They haven’t ruled out unification down the line, but IMO there are lots of UI challenges. Some things may not work on mobile data, or only work if the bandwidth is sufficient, so features must enable/disable on the fly and maybe have to do so depending on whether the phone is logged into wifi or cell network.
As implied by my first post above, I have done the same and with quite significant success - but the points that @Suedkiez made above remain valid and, in the presence of internet latency issues which can and do occur, I would expect the Roon app to break down before ARC.
If the Roon app works for you, good - enjoy and make the most of it as you will. But don’t be surprised if, on occaision, it does not work well. At these times, ARC will likely still work.
1 Like
Torben_Rick
(Torben - A Dane living in Hamburg - Roon Lifer)
13
Using Roon and Tailscale more often than not you don’t see the device as an endpoint due to Roons lack of vlan support. Whilst it may work for a while it’s never guaranteed. For me it’s so hit and miss it’s not worth bothering with. Also nothing in Roon currently is optimised for the latency you get over vpn.
, it’s likely to cause further support posts in a vast numbers, and hopefully not, but cause bugs elsewhere.
So far no problems 