Yes, DLNA/UPnP support was asked for a couple of years ago, and the reason for not supporting it were linked to in that thread…
I know all this, but paying 100 plus euro’s per year to have airplay through Roon to a high quality dac is just a waste of money. I know Roon adds a lot more than this with it’s fantastic interface and metadata. Just my two cents…
Adding upnp doesn’t seem like too much to ask. It’s a marketwide standard. From a support point of view it could even be an unsupported feature. Just implement it according to a standard. Those are there. Openhome would be preferable I guess. Most high end players support this and with bubbleupnp server most players can be supported through openhome.
Oh yeah, I’m really not prepared to have to add a third party device as a Roon endpoint. To me it just adds to an already costly hobby…
Products like the ultrarendu are great. But having to add this to get a roon endpoint…well you get my drift…
You could try a Raspberry Pi Zero with a JustBoom Digi Zero and connect it with TOSlink. You can install Roon Bridge on Linux and it’s really easy with DietPi.
Thanks for the suggestion. But I really just want to use my existing equipment without all kinds of bells and whistles.
Actually, we do. It works great on the squeezeboxes. It’s the UPnP bridge that isn’t passing it along.
Maybe Cambridge will adopt RAAT in the future. In the meantime, looks like DLNA/UPNP are your sources. There are inexpensive endpoints like RPI3 out there, but if you don’t want to buy additional equipment, looks like your stuck.
Thanks for the info Brian, I’ll get in touch with Phillipe (the author of the upnp bridge) to see if he can look into it.
I’ve already gotten in touch with Cambridge, I hope they do adopt RAAT and I hope it can be pushed through a firmware update. If they’re willing is a whole other issue, we’ll see.
A very versatile endpoint is the Oppo UDP203 if you might need a universal Bluray, DVD, CD, network player. You can track Roon on the TV screen via the Oppo.
Philippe is willing to look into it for me and I guess for himself too
He just doesn’t have any clue as to how Roon actually does this. His responses:
“How do they do that? the slimproto does not really include metadata, these are additions that are player dependent (none for a duet, for example). In the case of the bridge it shows itself a as squeeezelite and there is nothing to be sent. The way I get metadata is by the bridge querying LMS through it’s CLI interface, but Roon does not mimic that interface, hence my response”
“I don’t have any more a roon account. Maybe you can tell him to shoot me an email and we can discuss then. Or you can simply ask them if they have now enable a mimic of the cli service - they might have”
Would you be willing to get in touch with him? Or give me some directions to pass along?
If he could get this working somehow I’d be one very happy customer again…
They are free to contact me with questions, and I will help informally as I have before, but we do not drive this sort of communication from our end, as this is not part of our product.
For now-playing data, we mimic the interfaces that the SB Touch and SB Radio use, based on observing their behavior. I’m not sure exactly which subset of the LMS APIs that is, but it’s pretty straightforward to sniff the traffic going back and forth between one of those + Roon and find out. All of the source code for these protocols (both sides) is open, so there are generally few mysteries with Squeezeboxes.
Thanks for the info Brian, I’ll pass this on to Philippe, maybe he’ll be in touch, maybe he knows enough by your answer.
Pleasure doing business
Philippe emulates a squeezelite so according to him there is no wat to get this working. Pity.
Got an answer from Cambridge too, until Roon has a wider acceptance there are no plans to support it. Pity.
I’ve got one more chance: The upnp bridge from Sonore. I’m just not sure I’m willing to spend 300 dollars to test if it works…no guarantees.
@brian: Maybe you guys could rethink this still. There’s a huge market out there and my estimate would be that 90% isn’t Roon Ready at the moment. If you want Roon to be adopted IMHO you should at least have some sort of support for upnp. To me it doesn’t seem like such a huge task. There are all sorts of control points out there, but nothing that even compares to Roon. You guys have a unique selling point that no one else has, you should use it to gain access to this huge market. You might not get a substantial amount of extra paying subscribers, but I bet you would at least get many more. Wouldn’t that justify the time and money spent to develop and support this? I for one wouldn’t even mind if it’s unsupported (as long as it works )
UPnP is a big red line for us. It sometimes looks good from the outside, but is a disaster to actually support and use. We don’t want our user experience coupled to that one, and we disagree on technical/product levels with many of the choices that went into UPnP.
It’s not about the size of the task. We don’t want to support the UPnP ecosystem. We feel so strongly about this that we have spent much of our careers building alternatives at Sooloos, Meridian, and now Roon.
Not going to go into too much more detail–the topic of UPnP has been hashed and rehashed on this site since before we launched Roon in 2015. It’s sometimes a divisive topic–people do not always agree with our position–but we’re sticking to our guns on this one.
I understand Roon’s point of view and I wasn’t so ignorant to think that my request would make any difference, but is is a shame. However crude upnp might be, it does sound better than airplay to my ears. And even if it didn’t its a waste not to use the capabilities of my dac. So I guess I’ll just have to stick to my guns too and draw a big red line through Roon for the time being. I’m sorry to have to go, but paying 100 euros a year for airplay support is a bit too steep for me. When upnp gives me hi-res and dsd through dlna. I’ve got one last hope and that’s Sonore’s Upnp bridge. We’ll see if I can get some answers on that but I won’t hold my breath. Why I ask is Sonore developing this? Because it fills a hole that clearly exists and they see the market to fill it.
But enough is enough. Cambridge should just support RAAT, that would be my ultimate goal, but I guess I won’t hold my breath on that either.
Thanks for your answers Brian, even if you couldn’t help in this particular case…or do you have a contact at Cambridge you can nudge in the right direction?
It would be great to have UPnP support to use Roon with my Naim NDS.
Naim isn’t going to rework RAAT support back into their older product lines, although still current, as they are focused on the Uniti range.
I have the Sonore UPnP Bridge but I have found it has problems & limitations. Also it does not sound as good as native UPnP from Asset running on RPi on a lean OS. However I want something better than Naim’s own App.
I have Roon Core running on a NUC running ROCK, so I just need the best of both, Roon Library & Metadata management with a UPnP mode or an official Roon UPnP Bridge (with support).
It would be a great addition, as a user selectable mode.
Hi - I’m the upnpbrige guy I’m willing to help Michael a bit, but can’t spend too much time on that as all this is a hobby for me. My bridge is using the LMS CLI interface to retrieve metadata from LMS. Runs on port 9090, a simple interface. Obviously such CLI is not mimic’d by Roon, that would not make much sense for you guys. So, a quick question first: what do you do for devices like Boom? Last time I tried Roon, it was just displaying “Roon streaming” or something like that
We send text for the VFD display to the older devices. For a while, this was just a Roon logo, but later we updated it to show actual metadata–but it’s in pixels, not characters because that’s how the older devices work, so not too useful for this.
SB Radio/Touch are the interesting devices–since they pull nowplaying information over HTTP. This is all done using COMET (long polling) to keep the data up to date. It is over port 9090–but it is their current protocol. If you COMET subscribe to the
/slim/subscribe channel and pass an
id parameter for the zone, you should get the right stuff in response. LMS has a few generations of old protocols supported (including the CLI stuff you describe), but COMET is what the devices currently use for pulling nowplaying data, so that is what we support.
As I said above, the best way to figure this out is to sniff protocols to figure out what’s actually being used and read the source code for the details. It’s not really too complicated–one HTTP request to replicate and you should get good data back.
You may be able to use SqueezePlay software instead of an SB Touch if you don’t have one. I don’t remember if it works right with Roon or not, but it definitely works with LMS…
Thanks for the quick answer Brian - You’re right, I need to get familar with COMET, probably better than what I do now. I unfortunately started with CLI but I recently re-wrote entirely my UPnP/mDNS (for my CC/AirPlay version) discovery system, so seems that I’m on path of the v3 for the whole apps, the one where you know what to do and how to do it right re-writing the control piece is probably not such a big deal.
I’m getting more and more familiar with LMS Perl code, but that’s a long process for a one guy on spare time (and I already wrote many plugins…)
On a different note, you say you support sync with all sort of devices, does that include Chromecast with RAAT or AirPlay? If it does, does that mean that Google accepts to disclose how to drive CC in sync? That would be great and if you could give me any contact where to get the license and, I’d take it from there