What I’d love to see is more remote capabilities. For DSD I get it but there’s a lot of lossless and FLAC files that don’t need the bandwidth. Bits are bits whatever anyone tells you. And I worked with the Bell Labs guys at Lucent that debunked the whole gold plated cable malarkey.
What would be cool is an ARC compatible device that will talk to a Roon Core from a different subnet. The only workaround I see is either an iPad/iPhone Airplayijg to a device or a Roon-bridge VPN’d to the same network. And opening up ARC to more devices is taking way too long if they were ever serious about doing it.
Whatever purist engineers over there are thinking I don’t know unless just to sell to a high end crowd that wants to pay $$$ for Cores and not enable more attainable devices access to the ecosystem.
Love the idea of Roon but I feel there’s a deliberate closed ecosystem design at work here.
I have moved your post to a new thread as it isn’t related to the other topic where the OP was seeking community assistance for their setup.
Futhermore, you may want to review content in the help centre as you appear not to understand how Roon works.
FWIW, Roon works with more devices than any other player, and there is no tie-in to any products. Roon will work on pretty much anything Linux, macOS or Windows, and can use DIY projects or expensive off-the-shelf components, and anything in between.
Not sure what “an ARC compatible device that will talk to a Roon Core from a different subnet” means. Sounds like ARC with a USB DAC attached, which you can already do.
Love the idea of Roon but I feel there’s a deliberate closed ecosystem design at work here.
Funny to say when Roon is the ecosystem that speaks to the most third-party devices (except DLNA) and can run the server and bridges on Windows, Mac, and Linux.
So so are saying attach a DAC to an IPhone as an elegant solution? Please point me in a direction where there is an appliance device that can connect to a Roon Core not on the same “home” subnet that is not a phone.
You explained what you meant so poorly that it was impossible to say. For a mobile solution, it would be indeed quite elegant.
Now that you say what you mean, I’m sure that there are existing feature requests you can vote for in Feedback > Feature Suggestions. Or post in Feedback to blow off steam. Those are monitored by Roon Labs. Most likely, nobody from Roon will see your rants here in the user discussion category of the forum.
1 Like
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
6
ARC is exclusively for remotely accessing Roon using a celular network, public Wi-Fi etc..Many use a mobile device plus USB DAC when travelling.
Roon, Roon Bridge and Roon Ready devices are for directly connecting streamers, DACs, streaming amplifiers etc. to the server via Ethernet (or Wi-Fi) at home.
VLANs are not supported, but some have this working. However, this is firmly in the Tinkering categoey.
And all I suggested was the ARC evolved to allow more device types to connect from a remote subnet
Blockquote"What would be cool is an ARC compatible device that will talk to a Roon Core from a different subnet."
Blockquote
Not quite sure how much more direct and to the point you need it Suedkiez.
Blockquote Now that you say what you mean, I’m sure that there are existing feature requests you can vote for in Feedback > Feature Suggestions. Or post in Feedback to blow off steam. Those are monitored by Roon Labs. Most likely, nobody from Roon will see your rants here in the user discussion category of the forum.
Blockquote
Thanks for not answering the question because the solution doesn’t exist which was why I was asking and I was moved here just to shut me down from an engaged group.
And my original post that got moved here merely tried to point out that needed multiple cores or multiple accounts across different locations was cumbersome to users such as myself. I merely made a suggestion that obviously hit a chord that has been IMO a lacking feature of a platform that does have promise.
As is mentioned that ARC is for “exclusively for remotely accessing Roon…” so thanks for acknowledging what I pointed out is a limitation. Roon has a support gap between directly connected devices and remote devices. There are many users that don’t want to use a mobile device to connect remotely and why there isn’t more device support? You do not need to get snarky because I pointed out a gap that was clearly defined.
Thank you mjw, I think you meant to say VPNs instead of VLANS as a solution which I already mentioned is my workaround. It would be nice to have a way for an appliance (not a phone or ipad) be able to connect from a different subnet.
Now if you are defensive that there is an engineered ecosystem, I can tell you there is manipulation there or this type of feature would probably already exist.
Oh and BTW, I run product dev groups that have built over $5 billion in recurring revenue so please don’t treat my like a child.
And I even filled out the questionnaire that came out earlier this year regarding ARC features and development. This topic was ironically not included as even being explored as a future feature which again begs this is possibly a deliberate decision.
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
9
No, I meant VLANs because you talk about subnets, which refers to the subdivision of a LAN not traffic over the Internet.
Neither I nor @Suedkiez are being defensive. It appears that you are ill informed about the way Roon and Roon ARC work, and have difficulty conveying your ideas.
Roon supports many users, the vast majority are not technology professionals. So, the decision to support some functions and not others isn’t about what is possible, but what may be practically supported.
And finally, no, your post was moved because you hijacked another thread. It is now a unique thread in the same category.
OK, grow up and spend some time finding out about Roon and how it works. If it doesn’t meet your needs that’s fine, find something that does; or given your skill levels, build something that has all the features that you require.
OK. So VPNs and VLANs are not officially supported—understood. It sounds like this functionality is still in a “tinkering” phase, meaning users are left dealing with workarounds and inherent limitations in the software.
The original thread—and my main point—was this: if a user wants to access their Roon Core remotely, it would be a significant improvement if devices other than an iPhone or iPad using ARC could do so. This is a major limitation that’s repeatedly raised in the forums. To date, Roon has not taken any visible steps to resolve it, and it increasingly feels like this gap is intentional—baked into the design of the ecosystem.
This is misleading. Two LANs in different locations—connected via routers—are still subnets. Introducing VLANs into the mix only complicated and confused the discussion further.
On the contrary, I’m well informed about how Roon functions—and definitely more informed about networking in general. Many Roon users are, in fact, very network-savvy because they have to be. If you want a single Core to work across multiple subnets (which again, means either separate physical networks or segmented VLANs), you need to engineer a workaround—because the software won’t support it natively.
Which is exactly why I made the suggestion I did:
“What would be cool is an ARC-compatible device that will talk to a Roon Core from a different subnet.”
This would allow non-technical users—the majority—to enjoy Roon from outside their home network, or across multiple homes or offices, without needing to be network engineers.
What’s frustrating is that not a single one of my positive points or constructive suggestions were acknowledged. Instead, you picked apart selective terms to argue over, while ignoring the core request—which, again, has been echoed across your forums for years.
I even said I prefer Roon over Plexamp—which, based on Roon’s own May survey, is considered your direct competitor. I said the software has potential, that ARC was a meaningful improvement, and that expanding ARC to support broader use cases could make Roon a clear winner. But none of that was addressed—just dismissed with pedantic rebuttals over subnets and vague accusations of being “ill-informed.”
And finally, from another moderator years ago:
That was two years ago. Users are still struggling with this. All I asked was whether Roon ever plans to officially support what so many users have continued to request.
Regarding the claim that my post was “hijacking” another thread: I was directly referencing the same recurring problem that the original poster and others were discussing, admittadly a little snarky but obviously feelings can be hurt here if we don’t just say that the software is perfect and operating as designed. It’s ironic that instead of addressing the substance of the feedback, the focus again shifted to procedural nitpicking about where the comment was placed. Moving it to a separate thread doesn’t change the fact that this limitation affects a large number of users and continues to go unresolved.
1 Like
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
12
Tinkering is a place in the forum for those who choose to have unsupported configurations. For example, running Roon in a container or using VLANs. Roon doesn’t support these either. It’s not a limitation, but a choice.
Use Roon ARC for remote access as designed, or look at what others have done in Tinkering, e.g., run ARC in an emulator or sideload ARC on audio devices running Android. Contrary to what you write, the majority of users don’t consider this a limitation.
Looking at your forum stats, it’s clear you’ve spent very little time here, and don’t appear to know as much about Roon as you think you do.
That’s not what you described, and certainly not a consumer grade networking arrangement. Subnets are networks within networks, not two separate networks at different physical locations. Maybe, if you had simply said, “two locations”, you would have been understood.
Roon is a consumer product, and therefore, not designed to run on enterprise components. In contrast, VLANs are more common in home networks nowadays, albeit this is still unsupported because most Roon users wouldn’t be interested in this.
This is your opinion, yes. But, no, most Roon users do not need to be “network savvy”. And this is the point of the replies to this thread. Roon supports typical consumer home networks only, and it is not complex to set up. Anything outside the norm is for Tinkering, i.e., community support only.
I’m uncertain where you read this, but this is not a conclusion I would arrive at. Plexamp is not designed as a music player, and handles metadata poorly. Music enthusiasts are more likely to have come from another dedicated music player.
I’d agree with you here, but not as an alternative to Roon Bridge or Roon Ready devices. You are conflating two different functions of Roon. ARC is not intended for the purpose you propose.
It appears that you are thinking community moderators are the representatives of Roon. We are not. We are Roon users just like everyone else here. If you want Roon staff to read about your ideas, post in Feedback > Feature Suggestions. This was explained at the outset.
Roon’s support policy hasn’t changed. Moreover, no one is struggling with this as you suggest. The thread you posted on was not, as you say, about setting up Roon over multiple locations. It was primarily about connecting “multiple systems”, i.e., endpoints, in a single location. Using ARC at work was also discussed briefly.
You know, it’s always fascinating how pointing out an obvious gap in functionality suddenly becomes a lesson in how Roon “really works.” Thanks for the free seminar, but most of us here already know that ARC streams over WAN and Roon Bridge sits on the LAN—we can read the docs. The actual point (that seems allergic to acknowledgment) is that there’s no middle ground: no supported way for an appliance—anything not shaped like a phone—to cross a subnet boundary and talk to a Core without duct-taping VPNs, VLANs, or “tinkering.”
And yes, before anyone explains subnets again—two LANs routed together are still subnets, that’s not controversial. Claiming otherwise is flat-out inaccurate. Likewise, pretending that VLANs are some mystical enterprise-only construct is just wrong—consumer routers and mesh kits have shipped with VLAN support for years. And the idea that “most users wouldn’t care” is speculation at best—when the forums are full of people asking for exactly this feature.
What I’m suggesting isn’t radical: ARC already proved Roon can talk across networks. The ask is simply, “Why not expand that support beyond mobile apps?” If the official answer is “never going to happen” because it complicates the clean consumer narrative, then fine—just say it. But let’s not dress it up as if the limitation is somehow a feature. And please spare us the Moderator Theater—posing as if you’re speaking with the authority of Roon devs, while only wearing a “Volunteer” badge, doesn’t make your inaccuracies any more correct or your dismissals any more valid. And if this really should have been a Feature Request all along… then why was I moderated here instead of it just being moved there?
It would actually be refreshing if someone from Roon development could weigh in here for once, instead of this endless cycle of moderator conflation, interception, and interference.
And hey, if Plexamp can figure this out while still being the “metadata-challenged competitor,” maybe the “brain the size of a planet” crowd at Roon Labs could at least consider it without moderators needing to swat down anyone who dares point it out.
Blockquote
I’m uncertain where you read this, but this is not a conclusion I would arrive at. Plexamp is not designed as a music player, and handles metadata poorly. Music enthusiasts are more likely to have come from another dedicated music player.
From Roon’s own survey asking for feedback on the product
Blockquote
Blockquote
Roon ARC should have a desktop version so it can be used on Windows, Mac, Linux while out of home. This connectivity is achievable with a tool such as ZeroTier, but a ‘native’ solution would be much easier for all. I’ve read in other posts that this is not on the roadmap, can Roon provide their reasoning behind that decision?
Blockquote
“Roon’s support policy hasn’t changed.”
Right — and that’s exactly the problem. The policy hasn’t changed despite years of users highlighting the same gap. Repeating “hasn’t changed” as if it’s a virtue doesn’t make it less of a limitation; it just underlines the stagnation.
“No one is struggling with this as you suggest.”
Except… they are. The forums are full of workarounds, VPN setups, sideloads, emulator tricks, and frustrated “why doesn’t ARC just do this?” posts. Declaring that “no one” struggles while whole threads exist on the subject is just hand-waving. It’s inaccurate at best, dismissive at worst.
“The thread you posted on was not, as you say, about setting up Roon over multiple locations. It was primarily about connecting multiple systems, i.e., endpoints, in a single location.”
That’s a semantic dodge. Whether it’s multiple endpoints at one site or multiple endpoints across sites, the underlying issue is the same: Roon assumes everything lives on a flat, single subnet. Pretending these are entirely separate topics is a convenient way to sidestep the real limitation.
“Using ARC at work was also discussed briefly.”
Which is precisely the point: people are trying to use ARC in scenarios beyond a phone + DAC. The fact it was brought up “briefly” shows there’s interest, but it gets waved away instead of addressed.
Three years ago… and still not even a hint on the roadmap or even a discussion. That kind of silence starts to look less like “engineering priorities” and more like a deliberate business decision to keep ARC chained to mobile.
Yes, we all know about ZeroTier, Tailscale, VPN tunnels, emulators, etc. But let’s be honest: if the only answer after three years is “roll your own overlay network”, that’s not really a solution — that’s punting the ball to your users and calling it innovation. And frankly, ZeroTier isn’t some enterprise-grade magic trick — it’s not inherently more secure than a properly configured VPN, and it doesn’t do anything a VPN can’t already do. In fact it has major security implications. Recommending it as the workaround just highlights the gap.
What’s maddening is that the groundwork clearly exists: ARC already proves Roon can securely traverse networks and handle authentication. Extending that capability to desktop endpoints isn’t some sci-fi leap, it’s an obvious next step. So the real question isn’t “can it be done?” (we know it can) — it’s “why is it being avoided?”
If this is about “keeping things simple for consumers,” then fine — say that. But at least acknowledge the reality and limitations: a huge portion of your user base is already networking-savvy enough to run Roon, and they’ve been asking for this for years. Telling them to just keep “tinkering” doesn’t make the gap go away.
Three years later, still no movement. At this point, wouldn’t it be nice if someone from the actual dev team stepped in with an honest explanation, instead of leaving it to moderators to recycle the same “not supported” boilerplate?
I’ve had a ticket open since Jun 2 about some Roon losing all audio devices when Windows wakes from sleep. Have to restart the client app every time.
No word back on any investigation / fix of course…
I think I know what the issue is, and it’s probably related to a few issues I’ve seen on the boards. But given the general lack of support for what is it PAID product, I’m not telling them.
And before anyone says “they are the experts, you are just a user”, I think I have enough programming experience to make that comment.
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
18
I’m just a Roon user like you, and simply telling you how it is. For whatever reason, which is immaterial, Roon has decided not to support certain hardware and configurations.
That’s not a lesson, it’s stating the facts. Consequently, I have no interest in your essay. Moreover, Roon staff, as I already said, do not read this category, either.
My Dad was a boxer in the army and he’s bigger than your Dad and he drives faster and he can eat more steak and drink more beer and run faster and could have gone to Mars!
And i know what the answer is and i knew it first before you did and ive got a gold star!
I fully understand what’s being asked for here and see the point of view from all that have posted.
The way each individual would like Roon to work for them may create a vast array of differences. This isn’t something Roon could justify in implementing.
As we know Roon’s Feedback > Feature Suggestions that get implemented don’t fully make sense either. Some with very few votes get implemented, some with hundreds of votes have gone unanswered.
For the instance that’s mentioned in the OP, whilst isn’t supportedd by Roon, I would and can do the following.
DietPi OS running Roon Server and Tailscale at home.
DietPi OS running Roon Bridge and Tailscale on a RPi.
Set it up for subnet routing.
On my phone I’d install Tailscale and add it to the above subnet routing group.
Step 3 & 4 could equally be a laptop, acting as a bridge and client.
Although it might be easier taking the server with you. My secondary server is not much bigger than a Raspberry Pi. Some use a laptop.
Thanks for the detailed workaround—Tailscale and DietPi are certainly clever tools for hobbyist-level experimentation.
That said, the suggestion doesn’t address the actual issue raised: the need for Roon to natively support a single Core across multiple physical locations. These kinds of setups, while possible, are ultimately duct-taped solutions that highlight a deeper limitation in Roon’s architecture—it’s simply not designed for people who split their listening between, say, a home and a second residence, or a home and a workspace.
Suggesting a second server subverts the entire point of Roon’s centralized Core model. It fragments listening history, DSP settings, tags, and library consistency—the very things that make Roon compelling in the first place.
So again, I appreciate the tip, but it only reinforces the broader concern: Roon should be solving this natively, not leaving it to VPN hacks and sidecar devices that only a small subset of hobbyists will ever attempt.
