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.
Simon
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
Here’s a question for you @brian, would it be possible to allow the Extension structure within Roon to support audio input capabilities?
This would remove all responsibility from the Roon app/team for the support of less than palatable audio standards and place it squarely on extension developers. Providing some level of hook for an extension to step in and override currently playing music, or utilizing endpoints as playback devices by triggering the input for an extension would allow a developer to build a DLNA/UPnP compatible extension, or a Spotify extension, etc. Roon would still handle volume, zones, etc.
A huge amount of platforms that support third party plugins/extensions squarely place the support of those plugins/extensions on their developers, and not on the root application itself.
I suggested this approach as a solution for browsing by folder as well. Use 3rd party app to do so, but play through Roon to preserve DSP/Zones. Seems like this one approach could satisfy a number of requested needs.
In principle, JRiver is already that audiophile grade middleware via ASIO to DLNA. It exposes an ASIO inteface that roon recognises. Many on this site came to roon from JRiver and still maintain licences. With a BubbleUPnP server it provides access to chromecast as well.
The only thing is I cannot get it to work. JRiver integration seems to have been a hotish topic a few years back in the early days of roon. I don’t know if it is me doing something stupid or it’s just not supported anymore. I’ve raised a support ticket here:
I have no experience with JRiver. Are you suggesting that JRiver integration is possible with Roon via ASIO and through JRiver, DLNA?
Assuming that ASIO is still available, would playing something to a DLNA renderer through JRiver then transport that “signal” to Roon, thus playing on Roon and the various endpoints?
Edit: I read your support ticket. It’s the reverse of what I’d like to do with Roon.
All of my endpoints do support DLNA, but I don’t want to hit the endpoints directly as switching sources on the fly with music playing is impossible on those endpoints.
Roon should be the end all/be all with regards to audio playback throughout the house. Whether it supports other standards directly or through third party integrations, it needs to be the “master” of the audio network, so to speak.
I shouldn’t need to have two speaker systems in each room, one for DLNA and one for Roon in order to play back home automation notifications. Roon (or whatever other whole home audio solution exists) should support the ability to trigger an override on any currently playing media, either reducing the volume or muting it entirely when said trigger is enabled…
Instead of developing support for other standards into Roon, you add a couple of functions in the Extensions API to allow a “duck” or “mute” function from third party extensions, and then you add an audio channel input function. And you leave the actual support and development of the expanded features up to those third party developers…
Now, the Roon team doesn’t need to say “DLNA sucks because reason and we’ll never implement it”, instead they just say “You third party developers can expand the platform to fit your needs, and if you have issues, double check your code…” which they already do for the current extensions out there.
A specific example to my point above:
Roon is playing a playlist, and I’m enjoying it on multiple zones throughout the house. My home automation system is set up to automatically notify me when certain events happen, such as if the doorbell rings (another possible integration for Roon for smart doorbells), or if the laundry finishes. When the event(s) happen, the existing audio playback is reduced (ducked) from the 75% volume I’m listening to down to 25%, and the audio notification kicks in from my automation system… “The laundry is finished, please check the washer and dryer.” or “There’s someone at the front door.” then the audio fades back up to the previous level.
The third party extension in Roon could handle everything from being the audio sink for external sources (using basically any standard such as Airplay in, Spotify Connect, DLNA, etc) and the trigger that says “Roon, reduce audio and play this over the top.”
Roon should be the end all/be all with regards to audio playback throughout the house.
I think this is a good goal to have in mind–but it is not the goal of Roon as you’re using it today.
We have had many conversations about how to do this right. It requires high degrees of synchronization + low latency support–the latter is a capability that very few devices are able to meet, and usually only over ethernet. There are some WiFi solutions that are semi-low-latency within single manufacturer ecosystems. AES67+friends can do this over ethernet in mixed environments.
Generalized use cases for this include stuff like shipping TV audio around to speakers all over the house with lip sync. Today, this is mostly done using distribution amplifiers, and when done using networking (e.g. Dante), it is expensive and requires special hardware.
I think a mostly-pure software solution is possible…but stitching together a bunch of UPnP devices would not provide a good experience. You can’t do “ducking” if the audio device has a 10-30 second buffer delay. Nor can you work with many kinds of external sources.
We aren’t interested in “best effort” solutions that make bad experiences. It would be horrifying if Roon turned into Foobar–a loose confederation of extensions build by 100s of uncoordinated people that is just a total mess to use as a result. By avoiding that sort of complexity, we are able to bring music/audio experience to lots of people who won’t tolerate the mess/hassle.
Mess/hassle like this really isn’t opt-in, either. We’ve noticed that when we add complexity for the more technical users (even optional complexity), non-technical people come to this site and get absolutely snowed with those details by the technical guys, and walk away with their head spinning. People are thinking about things that they should never have to think about, because we exposed them to extra complexity. This is a tough line to walk, but one of the takeaways is: if we can’t do stuff in a really turnkey, smooth way, we probably shouldn’t do it.
That said–I’m not averse to adding an extension API that causes Roon to play a URL now, and possibly resume the previous audio afterwards. That’s something I’ve intended for us to do for a while, but just hasn’t bubbled up the schedule.
The other stuff–being a generalized audio sink, providing “audio routing fabric” for the home, etc, are things we’d like to explore in the future, but if we do it, it won’t be a band-aid, and we will probably prioritize a robust, modern solution over legacy concerns like including UPnP devices.
You can see in this thread that this is already failing–because I’m spending time guiding 3rd party developers and providing support to customers using this this UPnP extension. I’m here because our support team is tracking this stuff and bringing it to me, so they are spending time too. Somehow everything bubbles back to us even when it is “3rd party, unsupported”.
To the end customer on a Roon trial, they don’t really care who’s fault it is. We can still lose someone as a customer if this stuff doesn’t work well enough for them, and we are generally nice/responsive guys, so we engage. I’m not sure I want to expand this problem. It’s our job to keep the ecosystem around Roon simple, consistent, and easy to use.
No. I was thinking of much simpler use cases. If JRiver ASIO worked as a roon endpoint it gives “walled garden” access to DLNA devices not supported by roon.
roon → RAAT → ASIO → JRiver → DLNA
This may be enough for many. It is for the more technically minded as all the configuration of your DLNA devices has to be via JRiver not roon. But if you are maintaining a DLNA network you probably don’t mind that.
Just for context. JRiver used to be the audiophile player of choice but it had/has a lot of usability issues. A terrible interface and a reputation for complexity. There is a group, probably a small group, that came to roon from JRiver precisely because of the superior UX/Library Management. In the early days before roon developed DSP/RAAT/Convolution etc. integration with a JRiver that had all these features seems to have been more common. It’s similar to using HQPlayer for DSP rather than roon. I don’t know how common it is to do that with JRiver anymore. For some of us with DLNA use cases this might be a useful solution. I hope I can get it working. Here is an old link:
That’s the issue. I don’t want to maintain any part of a DLNA network, and I think that may be getting lost in translation with @brian’s response above in part.
I want a Roon network with whatever audio transports Roon prefers to use. But, I also have a service that only speaks out to a walled garden (Sonos) or DLNA… Allowing an extension attached to Roon to listen for a connection and then have a modicum of control over Roon would allow Roon to pass audio over its own transports to its own endpoints.
I definitely understand the concerns about having a huge amount of plugins complicating things, and I understand the concerns about “wasting time” (my words, paraphrased) with supporting the community. I feel that the former is very valid, and the latter is dismissive at best, but I DO understand it.
Technical people look for technical features. Non-technical people think “that’d be nice” and then look for technical features. If “Developer” builds extension, “Developer” supports extension… A community is built by those who participate. Saying “You can see in this thread that this is already failing–because I’m spending time guiding 3rd party developers and providing support to customers using this this UPnP extension.” does not automatically mean that the community participants won’t provide support for the plugin. I have to be honest and state that this is one of the few “technical” communities I participate in in which the creators of the product the community is based around actually participate. XDA developers don’t say “Go talk to Google because my custom ROM doesn’t work right for you”… The developer of the custom ROM supports it. It’s a solid community. SmartThings uses the same forum software as Roon does. The developer supports their SmartApp… If something the dev does makes things not work, SmartThings says “That’s a community app. Talk to the dev.”
In the end, Roon is a good product, but limited to specific use cases. It doesn’t need to be a Swiss Army Knife of audio applications, it just needs to be the best at what it does. Adding functionality isn’t simple, but doing so could allow others to use it as a Swiss Army Knife. Even non-technical users won’t play with a knife with a blindfold on.
I’m excited to see that URL playback has been thought about. It would be a stopgap for those of us using the audio notifications within specific automation systems.
The first concern is the only one. If I were concerned about wasting time in support or dismissing the issue, I wouldn’t be here supporting these guys and advising the UPnP bridge developers on how to get it working and discussing with you.
The point I was making is: whatever the direction we let things go, we are the ones who are accountable for the end result. Whether problems arise via support burden, complexity for new users, ending up with a product that is unable to evolve, or any other foreseeable or unforeseeable consequences. We are on the hook for what happens.
Smartthings has no choice. They must interface with 10,000 products and the market/business environment they are in doesn’t allow them to be picky about quality. They must get it done so fast that they could never do it themselves.
But, because they have done things that way, their product is awful. Even popular integrations that should be bang on reliable (like Google Home in my house) don’t work at all. Integration stuff that should be easy (like assigning devices to Rooms) ends up as a repeated task because their integration APIs were done poorly. Support for the actual usability problems is non-existent. Infinite buck passing between them and their developers. I hate it. I’m actively seeking alternatives.
Foobar is worse than that. Every time I need to set up a new install and do something that should take 2-3 clicks like getting DSD playback going, it takes me half an hour of reading guides and figuring out which plugins I need to install and how to stitch them together. Bleh.
That isn’t what I want Roon to become.
We do a lot with 3rd party developers, but not in the way you think–most of it is through certification programs, where we establish business relationships that make sure that the level of quality is very high.
We have extensions APIs pointed at areas of the app where they won’t create a ton of complexity, but will add value. I’d like to do more with that over time–one of our big holes right now is that we don’t provide an easy place to host/run extensions, so they are largely inaccessible to non-technical people.
There is absolutely nothing wrong with playing a URL…but there is something wrong with making a sloppy entry into becoming “audio routing fabric” for a household by doing it in a patchwork way.
I completely understand that. Thank you for saying it as succinctly as you have, and I greatly appreciate your patience in this discussion.
This I can also stand behind. For the record, I love Roon… It is very good for what it is, and I’m using it at home with numerous Airplay compatible speakers/endpoints… I’d use Roonbridge, but Raspberry Pi units are expensive compared to Pi Zero W units… I’m not in a position to afford high-end audio endpoints that have dedicated Roon support, so I tend to build the majority of my own stuff… My Roon system is controlled using a 22" touchscreen embedded in the wall in portrait mode… It’s a great piece of software. I’d just love to see more integration capabilities with it… And I’m likely an edge case with regards to the whole use we’ve been discussing…
Re: “Audio Routing Fabric”… That’s the best way I’ve heard it expressed so far. Roon has the potential to fill that role and would make it THE software for whole home audio for both the average consumer and the enthusiast.
Thank you Brian. I’m not trying to be difficult. I’m a relative newcomer to the community and am loving Roon the way it is… I just have grand visions of my audio system being more than a disparate group of components that don’t talk to each other.
I had no expectations but I am absolutely amazed how good JRiver to just a regular chromecast out to a newish flatscreen TV sounds (I don’t have a Chromecast AUDIO). It really would be great to get this working with roon.
As @brian points out in an old thread JRiver exposes both a WDM interface (WASAPI) and an ASIO interface. The ASIO interface is a default in JRiver. The WDM interface is optional and well hidden (as usual in JRiver) and you have to switch it on (Tools->Options->General->Features, scroll down and tick the very last option). If you do this then roon now recognises two JRiver end points and you will see this:
But I get no sound on the WDM JRiver endpoint either. More seems to happen than on ASIO in that there is progress on the waveform you do not see on ASIO. But there is still no sound. Signal path looks like this:
It didn’t quite behave closely enough to a sound card to make RAAT’s clock management work
It had dropouts sometimes that I could not trace back to a cause on our end.
It sometimes exhibited funny behavior around the start of streams (dropouts, weird sounds, etc)
RAAT is pretty dependent on having accurate latency measurements + clock progression (for WDM/WASAPI) reported by the drivers. Most apps are not quite this demanding that things are implemented right in the lower levels.
I suspect that even if we were to get it working at a basic level, it would still be pretty brittle.
Keep in mind that the last time this came onto my radar was probably middle of 2015. Very different time. Maybe it’s gotten better/different. I don’t think anyone has mentioned it to me since then, so I can’t imagine many are using it.