Can ROCK run Roon API?

Last time when I run Roon Core on Mac OSX, the Roon API extensions run very well, but it seems to me when I switch to ROCK, I am unable to run Roon API, is this correct?


The API has nothing to do with Mac OS or ROCK… it’s provided for by Roon.

Or are you talking about where to run extensions?


Yes, I am talking about running extension. It seems to me that I need to install a few things on the Roon Core … does ROCK allow me to do that?


not yet… ROCK wont let you install anything.

We are looking into a way to run sandboxed extensions or services there, but it’s not ready for prime time yet.


@danny - so as things stand if you’re running ROCK as your core, you aren’t able to leverage the API until this is addressed? Or can extensions be run on the Bridge?

Extensions can be run anywhere the writer of the extension allowed. The thing I speak of is a “app store” like simple click and install of extensions

Thanks… I’m getting it up and running on one of my RPis which will always be on. Got you - it will discover the core and register with it. Regardless of if it is running ROCK.

I have a few Pi on my system now. Can the node.js stuff be run alongside the room bridge software? If so where can I find install instructions?

If memory serves correctly… (and assuming you’re running linux and use apt-get).

sudo apt-get nodejs
sudo apt-get npm

You may want to check for updates first.

I think we all know the first rule about assumption club.

Thanks; a related thread here for Diet-Pi:

Roon bridge won’t run on a pi zero…node.js might tho not sure

Thanks, my enquiry was in relation to a Pi 3, so should be fine with the same install instructions.

@danny did anything become of ROCK being able to run sandboxed extensions, it would be so good?

it’s still on the todo list, but we’ve been focused on other items.

Is there any update on running extensions with ROCK?

@danny, same questions than @Brett_Kerbel

Is there any update on running extensions with ROCK?
because the alarm function would really be very useful to me !


Would docker be an answer? Perhaps with a custom UI to manage it (via docker commands) and preset the appropriate networking mode (host, or a suitable preset bridge mode) so that end users do not have to really understand anything about docker? All they would have to do is point at the appropriate repo and install.

Many extensions are already available as docker images for linux-x64 and some for linux-arm. The downside is with node source based images, they can be quite big (600-800Mb) if using a standard node base image. Some however are a lot smaller - Deep Harmony image is about 105Mb as it is compiled to an executable so it only needs a very basic base image and currently uses Debian 9.5 slim (~50Mb + 55Mb for the compiled node 10 js). In the context of typical disc drives, a few gigs taken up with extensions is really a non issue. The biggest concern is their CPU and memory use - again something that docker can help with.

In future we may start to see more extensions written in python or .net with the 3rd party SDK ports that have been done. The other consideration is logging - some extensions just rely upon basic console logging captured via docker (or otherwise), DH has a rolling log. Again - docker helps here because you don’t have to care at all what run time is being used.

A downside with docker is generally you replace the entire image which would normally mean that extension config is lost, however in cloud apps you generally have an image for runtime and another mount for data (if needed) so you can preserve the data while blowing image the image for an upgrade. A documented standard per-extension mount point managed by Roon as part of extension install would probably make this easy for extension developers to adopt.

Some extension already do their own in-place updates (download binary and restart - DH does this) which work fine in a self contain docker image, but it doesn’t change that occasionally you may want to refresh the entire image as well which is where a separate per-extension data mount would help hugely. You might expect such data mounts to have to accommodate config.json and maybe a logs folder in some cases (DH has a disc based rolling log for convenient zip and download by users) or perhaps some other cached/accumulated data.

On the networking side, I doubt that extension have requirement much beyond what Roon already demands (multicast/broadcast discoverability - ie send and receive both. DH for eg both uses SSDP to discover other services and itself is a multi-SSDP server as well as providing a web server with api, content download and websocket endpoints). The biggest issue may be port clashes is using host mode networking. Bridge mode networking may mitigate this if it is deemed to be a concern.

Info on docker volumes:

Info on bridge networks

In case multi-platform is a consideration, as I understand it you are only going to get fully working bridge/host modes on a linux host running a Linux image (seems to work equally well on x64 and arm on a PI 3B+). macos cannot be docker-ized so macos support is out. Windows can be docker-ized with windows server core and windows nano base images. Linux images running on macos or windows based docker run in a full virtual machine on a virtual network and thus are completely unsuitable for Roon from a networking perspective. TBH the virtual machine may become a resource concern as well, so I do not suggest running docker on either. Windows hosted docker running a windows based docker image may be viable, but if the target is ROCK only, then I would ignore that complete as just too messy to deal with and support. Docker on Linux seems quite lightweight - I even run several images on a R-PI 3B+ alongside Roon bridge with no ill effect on the bridge at sample rates upto 192k.