ROCK-R (Roon Optimized Core Kit Remote), rock·er | \ ˈrä-kər \

Roon Optimized Core Kit Remote, ROCK-R (rocker), is a ROCK-like installation (NuC hardware) used at a “remote” location. It gives you full access to your library but is intelligent enough to either pull streaming content directly or files on Core over the ROCK Link (RL). The list of Audio Endpoints are local to that ROCK-R and there is no control of endpoints on the Home ROCK.

Here’s the basic idea of how it works. After install of ROCK-R you connect to it with Roon Remote. It knows it is ROCK-R so asks for your Roon user / pass (it cannot be provisioned as a Core). After authentication you’re presented with details of your active ROCK Core (version, IP, HW, etc.). After selecting the Core an encrypted tunnel is established between ROCK and ROCK-R. That encrypted tunnel is the ROCK Link (RL). ROCK-R uses the RL to replicate / sync your database updating file locations to be across the RL.

As a user, Remote would function the same way it does today after the DB was replicated. You’d see the local audio endpoints for selection. You’d see your entire library, playlists, streaming services, etc. The only difference is audio files get pulled across the tunnel. Streaming services are served from ROCK-R (direct file pull from streaming providers). You need local audio endpoints in the ROCK-R location.

Some nice to haves (more details):

  • I’d like to see the ROCK Tunnel use WireGuard (https://www.wireguard.com/). This can be dynamically provisioned, including the certificate / key generation, and pushed down to the ROCK/ROCK-R from the orchestration service which would live in the cloud.

  • Ability to add files to the Core. From the ROCK-R network it would be nice to add files to CORE.

  • Delta sync or journal based DB sync. I should be able to leave my ROCK-R off for long periods of time, come back, and only sync the changes.

  • Handful of ROCK-R’s. Maybe not unlimited but at least 5 ROCK-Rs I can throw into the world all connected to Core at the same time.

  • Transcoding / Transrating. Being able to limit the file size being transferred over the tunnel is beneficial. Even the ability to convert from FLAC to AAC/MP3 when coming across the tunnel.

  • Local quality settings for ROCK-R from streaming services. I’d like to set, say, Tidal to Hifi on ROCK-R but leave it as Master on ROCK (home Core).

  • Cloud based monitoring / troubleshooting. ROCK / ROCK-R should report their tunnel status to the cloud. I should be able sever a connection between ROCK/ROCK-R from the cloud as well or force a re-provision (new certs / keys).

  • ROCK-R should support Wifi to access the internet. Sometimes the only internet access available is a wireless hotspot. This can be provisioned via keyboard / monitor or ROCK-R can broadcast its own provisioning network and web interface whenever it fails to connect on a known network.

  • Allow for the OEM of ROCK-R. An all-in-one streaming DAC supporting ROCK-R is my ideal “second-home” system.

Thank you.

3 Likes

I think library sharing to rocker sounds like a very interesting sub feature of the overall idea.

1 Like

[Moderated]

I thought the explanation was over the top until I clued in that this is a guy/girl has a dedicated Roon Core at home, has multiple, dedicated end points there, and then has a second home/office that they have enough authority in to install devices on the network. Likely a second home, summer home, weekly city apartment, etc. type situation.

That’s a hell of a lot like me, and like my colleagues, and like my audio friends, and like my parents. In my case, I change where I work in the summer and get screwed not being able to use my own Roon system there because my hardware investment back home isn’t mobile. This guy’s idea is a VPN style tunnel, just honoured by Roon.

[Moderated]

Yup, you’ve got it. That’s the various use cases. As soon as this pandemic thing is over I could deploy ROCK-R in a couple different places where I control the network and/or have access to a stable connection. The advantage of cloud provisioning is you get some control of ROCK from a remote location. ROCK can do things like report its health, you can tell it to reboot, etc. and troubleshoot it remotely just like it was a real “cloud service” except it still lives on your home network.

To address the “netflix sharing” issue… I think two reasons why people would be hesitant to abuse the feature:

  1. Security - Giving someone access to my netflix account, at worst, screw-up my recommendations. With Roon that person truly has access to destroy my Core. My parents destroy computers by looking at them. They will not be getting a ROCK-R :slight_smile: Just not worth the risk.

  2. Pay for each ROCK-R. Put a monthly fee on it and there will be little abuse.

  3. Although, I’m not a fan of this option, Roon could limit playback to 1 ROCK at a time. Start playback in a ROCK-R zone and playback stops in the home zone. Play in a home zone and ROCK-R playback stops. This is how Tidal and a number of other services do it. Since you can only physically be in one place at a time it makes sense.

But, Mr. ipeverywhere what if I’m traveling and my roommates want to listen at home? Charge full price for ROCK-R and remove the 1 zone limitation.

Anyway, these are just some of the ways to eliminate the “netflix sharing” problem.

Each roon instance should check upon startup the available licenses. If there are more than one (say two in total), it could of course play simultaneously in the 2nd location as well (say for a different family member), otherwise deny service. So, this would eliminate any abuse of licenses as having one license will allow for playback at only one location at any given time. Same as it is implemented in Tidal for example.

Having users implemented in roon makes it fairly easy to keep roon DBs in sync between the different homes and allow for the right direction of the sync (as a user can be only in one home at any given time playing, so replicate its DB changes to the other homes).

I don’t see ANY need to differentiate between roon and roon-remote. It should be standard functionality in roon. No need to have a roon-remote kind of limitation, as there shouldn’t be any difference between the homes/locations.

roon, are you listening??

I don’t want to pay for a full license at my secondary location(s)

This does make the solution much easier from a licensing infrastructure perspective. As much as I don’t want to pay for a second license I probably would if it was implemented as core functionality.

Of course, with a single license you should be able to play at ONE location only, regardless which one. And without any restarts or register/deregister. As easy as it is implemented in Tidal (as an example).

One roon user should be in ONE location only.

Syncing the user (DBs) between locations should be standard roon functionality.

Is roon listening at all?

They listen but have a policy of non-response. I agree with that. It’s fun to play Product on the Internet but they don’t need to disclose their future plans for the app. Often times that just leads to problems and complaints. So… I make my voice heard but it rarely ever turns into a conversation.

2 Likes

Having a conversation and being actively involved, I bet the product will be much further.

I have written here a simple way of logic how to implement this, easier, relying on site 2 site encryption. It shouldn’t be roon’s task to go via Cloud and/or encryption. Just connect multiple locations (or reachable server on multiple subnets) and sync remote libraries.