I’m a newcomer in Roon infrastructure and, first of all, need to say that Roon is the best solution I’ve ever seen for organizing my music library and enhancing my listening experience. Thanks for that product, guys!
So, now I’m studying Roon ecosystem and see, that Roon ARC a soft that is everything we need for total Roon ecosystem experience. As far as I understand, Roon ARC includes Roon client (remote) + gives a limitless functionality for streamig my music wherever I go.
Giving that, the question is bound to arise: are there any disadvantages or problems to use Roon ARC instead of Roon client even in local network? Do I really need a Roon client soft?
Thanks in advance for your comments and helping to understand Roon.
Maybe somebody knows, are there any technological differences between Roon client and Roon ARC in transporting the track or any other technical details, that can influence on track quality, if we use “bit-to-bit” mode?
I use the following setup: Roon ARC on iPad / Roon client on iPad → Fiio Q7 as DAC → Violectric dha v226 as Amp → Audeze LCD-XC headphones, and, frankly speaking, don’t hear any difference between Roon ARC and Roon client in listening…
Aesthetic issue is that ARC app for iPad it’s just iPhone app, and looks scary on big screen, but I think Roon Labs will prepare a special app for iPad soon. Let’s try to find any other issues
If the music/file is the same, and if the quality and general playback settings are the same then you shouldn’t be able to tell a difference playing it Roon or Roon ARC.
But… Roon is designed for your local network. Roon ARC is predominantly designed for listening outside your network on the go. I don’t know the exact way they each handle the data, but I assume that Roon ARC works slightly differently to Roon in order to stream, hence why it needs ports to be open, and static IP address.
As far as I understand it, Roon ARC was introduced as a standalone app partly to allow the team to test it out, focus on its strengths and weaknesses, and not to put load on the original Roon app (or annoy users using Roon who had no desire to stream outside their home). But the long-term intention was always to bring the two apps into one, at some point. Or at least combine some of the functionality of Roon ARC into the main Roon app.
One use case for this I can think of is being able to continue Roon playback immediately on Roon ARC as you leave your home, treating it kind of like another zone in your network. This works the opposite way too, of course. If I could walk into my house and immediately just switch my Roon ARC playback to my Roon setup, that would be amazing.
Anyway. The two apps do have overlaps, and there might be more in future. But ideally you should be using Roon in your home network, and Roon ARC outside your home network. That’s what they are designed for and do best.
ARC, being primarily intended for mobile playback, has additional settings for converting music data to lower bandwidth, which are enabled by default (but can be disabled)
In addition, ARC also has some DSP options. (Called MUSE in Roon).
The main Roon client has similar options by using more powerful DSP, but they are off by default
If format conversion and DSP is off, then both ARC and main Roon are bit perfect.
In addition, ARC uses larger buffers, again to increases mobile (primarily cell network) reliability
Main Roon uses a different protocol with small buffers for LAN playback, RAAT. This can do many more things, such as synchronized playback to several output devices.
It doesn’t really have to be static. It can be dynamically assigned by the ISP, but it needs to be a real public IP address (not CG-NAT at the ISP).
At least this was the case as long as ARC relied on port forwarding when used from outside the home network. (Inside the home network it always just worked, but in this case the regular Roon client is most often the better choice, like you wrote).
Nowadays, of course, ARC can be used with Tailscale, and then it doesn’t rely on port forwarding when used from outside the home network.
So, as I see, there is some technological difference between Roon client and ARC, but not really serious if we speak about the quality of the sound. Also I got some scenarios, where ARC can’t be useful - for example network with a few local zones for listening.
As s result, I don’t really understand the idea to keep two apps: one for local network and another - for internet streaming. We don’t know all the issues, but it looks obvious to merge two apps into one powerful Roon app both for local network and internet streaming. So, I hope it will come sooner or later (prefer sooner )
My question about the difference between ARC and Roon client wasn’t theoretical. I have my own case, when my Roon server is at one home, but I have to spend a lot of time in another home outside the country. It’s very uncomfortable to have two duplicated Roon servers in two countries and to solve the sync problem between them. One powerful app (Roon client + ARC) will completely solve such type of problem. Thanks God I can use ARC as of now, and, as we discussed, no difference in sound quality vs Roon client. Maybe somebody in this discussion will find the critical difference between these two apps, and in this situation only VPN will help to connect all my devices in two countries into one virtual local network to use Roon client only (would like to avoid such sitation).
The Roon home app is far superior, imho. But I do understand having a standalone app for mobile.
If you added the ability to ‘download’ tracks for on the go to the normal Roon app, for instance, it would cause a ton of confusion.
And I can think of other reasons to keep them separate that are more to do with the technical function of the app(s).
I doubt the ARC app will disappear completely. Rather some of the Roon normal app features and design will find their way into the ARC app, until they look and act pretty much the same. But the apps will always remain separate to some degree.
There was lots of discussion about it and they said they could have gone either way. But as the network stack is completely different (RAAT will most likely never work reliably over a VPN across the Internet because of the latency) and they didn’t want to risk destabilizing the main app, they decided to keep them separate during development. I suppose it also helped them keeping separate teams, and they could base ARC on a completely new development framework.
They never ruled out later unification. I would bet that if it happens, it will be by adding features to ARC.
While two apps for different purposes may be a bit confusing, I’m sure it would also be confusing (and cause difficult design work) if a single app kept changing available features depending on the network you are in. And this would necessarily have to happen because some ARC features would be confusing and useless while on the home LAN and regular Roon features would be confusing or outright impossible to enable if the phone moves to a cell network.
@Suedkiez , thanks, this is a significant reason to keep two apps separate at the moment. I know nothing about RAAT protocol, but guess it needs huge bandwidth and extra-low latency - it’s almost impossible to realize via cell network.
So, let’s see which the development track of Roon apps will be, but I believe the future is for ARC setup, and I agree with you - most part of development effort will be focused on ARC.
Depends on what means when saying „discovering“. ARC doesn’t have the Focus feature of the main app, for instance.
It’s not all that complicated:
At home, the regular app is much better. (With two exceptions: 1. if the phone has a marginal wifi connection and one wants to use the phone as the output. 2. Scrolling on 120 Hz phones is smoother on ARC).
