ARC Design Question

Does anyone know what the differences are under the hood between ARC and a standard endpoint? I’m beginning to wonder why the developers didn’t just make a modified standard endpoint rather than a whole new beast.

For instance, aside from discovery (mDNS) issues, what about a standard endpoint would not work over a WAN?

Great title, I’m sure after 5 minutes of thinking about it you know so much better than the people who built it that you can declare a fail.

It has been discussed and explained before. The network requirements with internet streaming are totally different and hence the network stack is. It was faster to bring to market without having to ensure not to cause problems in the regular remote. It’s a trade-off and there are pros and cons to each design choice, and that’s the one they made for now. Convergence in the future is not ruled out.

IMHO there is ample potential for confusion with one app because necessarily the UI would have to change depending on the network you are on, as ARC probably will never have all features of the remote, and has different requirements. So then whenever people don’t have wifi enabled on the phone the UI will differ.

https://community.roonlabs.com/t/arc-roon-will-they-converge-speculation-or-perhaps-feature-suggestion/206827 (closed area from early testing, may not be visible to you)

This post (also in closed area) explained it best:

https://community.roonlabs.com/t/roon-mobile-cant-switch-zones/202409/5?u=suedkiez

I hope it’s OK to copy:

[actually I deleted that. I think it would be good to have this info available for everyone instead of having to paraphrase it, but not going to break any rules for this thread. Moderators can post a screenshot if they think it’s worth it]

5 Likes

Geez, man, I don’t get you. It was a question (see the question mark at the end?)

In any event, other than giving me some generic generalities, you haven’t answered the question. Maybe if you don’t know the answer it would be better not to chime in? Roon doesn’t need defenders . . .

A question with an agenda. You could have just asked, what’s the point of insulting developers?

It’s the best we have and it’s (paraphrased) from Roon staff. Good luck waiting for a better one. I’m sure they are eager to drop everything after being insulted.

And a bit funny being unable to take a bit of blowback after dishing it out. I made one comment at the start before spending time and searching for you to give you more info - what you could have done yourself by searching “arc separate app” on the forum.

2 Likes

This I can’t agree with. PlexAmp manages this seamlessly with no issues. Same app on local or out of house their is no difference in operation at all.

1 Like

I think this is best kept to the older thread where most of this was discussed before :slight_smile: I don’t know the Plex app but on the other thread some people said that other streaming apps also manage - but these other streaming apps simply don’t have any additional complex features when on the home wifi, so I don’t think that’s a useful comparison.

On the other hand, Roon on phone is limited too. Anyways, they have said they might converge, but for now they made that choice because the other options would have been a magnitude more complex. Hardly a fail or whatever :wink:

@Simon_Arnold3 What’s more, there are those who have managed to get layer 2 VPNs working. Really, the whole “different network stack” thing is nonsensical.

I suggest you try it out as Arc pails in comparison to PlexAmp. Whilst it’s not a feature rich as Roon for at home it’s catching up and it is overall a far better online/offline application. Same app is used for both home and away the same features are available its slick and doesn’t have the server issues plaguing ARC or as many network issues as it handle UPnP far better and double NAT situations.

1 Like

It’s a nonstarter for me because it doesn’t have any of my extended metadata edits from Roon. For just playing I could use the Qobuz app as well, but the metadata is really nice for me. And I have no ARC issues. I appreciate that it can be a challenge when new to ARC, but all done (and the hardest part was talking to Vodafone)

Fair enough but it shows how one app can do either function very well. It shows how last minute arc actually feels and given it’s stability it definitely was released far too soon.

Not sure what you mean here. VPN isn’t a workable solution for most users at all and is full of problems of its own.

Like what? mDNS doesn’t work over layer 3 vpns, but it will work over layer 2’s. People have them working, so that indicates that the internet isn’t a problem for the underlying technology (i.e., other than the discovery bit).

People have raw PCM data over RAAT (with the very small buffers it uses) reliably working without dropouts over phone networks?

Not sure what you are referring to here. Using ARC via a VPN instead of port forwarding? If so yes it works for some but it’s bandwidth heavy, battery heavy on a the device and would require licensing which would increase costs. Roon as on a local network Roon doesn’t use mDNS for discovery of RAAT audio zones it uses UDP and using vpn here is very hit and miss and tends not to work at all for ROCK users. It’s requires far much more knowledge of networking than port forwarding which works fine when done right as in PlexAmp.

Just to say that I have a L2 VPN, and so was able to use Roon remotely before ARC was released.

The network discovery and streaming code designed for a local network was clearly at its limits used in this way. Endpoint discovery wasn’t always reliable, playback was sometimes interrupted etc.

Arc is very much more reliable, with much larger buffers playback buffers, locally cached library data, direct streaming from streaming services, ability to download etc.

There are very many different design criteria (eg no need to sync multiple endpoints, no need to split remote and output) involved in the apps. In some cases these directly conflict (eg buffer size).

2 Likes

ARC has been iffy for me. In any event, the basic point remains the same: there is nothing inherent in the streaming of music over the internet that differs from LAN streaming. VPN overhead my be a problem, but as @Simon_Arnold3 pointed out, other software platforms do it quite well with simple port forwarding. The rest of the issues you mention are just parameter tweaks, not fundamental issues with WAN vs LAN.

Am I missing something? (And I’m still curious what exactly actually is different under the hood.)

[edit]Good point about downloads for subway listening.[/edit]

Latency and throughput, quite obviously. RAAT is tightly coupled with small buffers to ensure in-sync multiroom. Hell, the forum is always full of posts with people having dropouts on their home wifi. I couldn’t play to the regular remote when I walked out the terrace door because my Motorola phone’s wifi module was less than perfect.

On phones in cell networks, the connection regularly goes away for minutes and throughput is fluctuating in the best case.

Really, the two use cases are more different than similar in this regard

What about users like me for whom ARC has worked flawlessly from its first release? Should we have been denied the opportunity to use it just because some users have convoluted networking issues?

2 Likes

I was thinking the other day about the promo video when Arc was rolled out. Somehow I can’t see all those youngsters mucking about with port forwarding. By the way, once I changed the setting in Arc to original quality it started working much better for me. I keep a few albums downloaded just in case. If they would just make it so I can at least see my bookmarks I’d be a happy camper.

1 Like

I dunno. Every Xbox or PlayStation needs the same for online gaming