Roon / RAAT Architecture and protocol VS DLNA / UPnP AV

Roon Software Discussion
1

Hi all,

I think it would be useful to post a synthetic paper or blog post to highlight the major ROON and RAAT benefits VS UPNP / DLNA concurrent solutions.

There is already some elements:

  • On the knowledge base a good Roon architecture presentation and RAAT design goals. Very interesting but seems a bit too technical and audio makers oriented and there is not element to compare against UPnP.

  • Here on the community site What’s wrong with UPnP? is also interesting but lacks of explanation on why UPnP is “twonky”.

I know a lot of users seduced by Roon User Experience but not understanding why it is not possible to get such a good experience being UPnP compatible as the great majority of the existing Player / Renderers support this “standard” and a few are not too bad (Lumin, Auralic controlpoints, with Minim or Jriver servers).

I know the Roon team is very busy but I’m convinced such a presentation would help Roon user base to grow-up.

Regards,
Herold

2 Likes
2

This thread contains posts explaining relevant differences.

3

Thank you @andybob, interesting thread but too SQ, clock oriented, and technical for the average user.

I think a paper about how the ROON VS UPNP technical differences leads to a different UX would be useful.

4

The only difference in UE would be in the SQ. so, in that sense it is already covered.

5

Twonky isn’t an adjective. It’s a piece of software that (in that discussion) represents the “typical” UPnP media server/control solution.

6

I agree, it would help to have a more organized article directly to this point.

The only difference in UE would be in the SQ. so, in that sense it is already covered.

There are UX differences beyond sound quality.

One example–in UPnP, if a new streaming service or file format hits the market, each endpoint needs a firmware update independently, and each vendor of endpoint hardware needs to make business relationships to make that happen. In some cases, patent licenses or royalty payments are involved, and in many cases, products are “left behind”. This can lead to situations where certain content can only be played in certain rooms (something we consider totally unacceptable because it makes it difficult for less sophisticated users to operate the system).

Another example–have you ever seen a UPnP based system where the zone controls, queue, transport, volume, etc stay in perfect sync across multiple remotes in real-time? I haven’t. We consider that kind of thing to be a basic requirement for releasing product, but UPnP is not built to the same standard.

There is no widely supported standard for doing synchronized multi-room playback over UPnP (AV 2.0 addresses it one way, OpenHome a different way, and AV 1.0 ignored the problem). If you intend to mix heterogeneous devices (multiple vendors + device ages), getting multi-room synchronization working ranges from difficult to impossible with UPnP.

There is some related content in this knowledge-base post–not totally directed at your point, but the “Why Not Decentralize the Core” section is basically a comparison with UPnP and similar technologies at the product architecture level.

3 Likes
7

Thank you very much @Brian and sorry for misunderstanding the word “Twonky”, I’m french.

I’m also convinced UPnP technical architecture leads to UX differences VS Roon’s.
IMHO SQ is not the problem with UPnP but global UX is.
The knowledge-base article you post about Roon centralized architecture is very clear and instructive.

Perhaps a dedicated article mixing what’s wrong with UPnP, this article, and some “real life” use case like those you give in this thread, would be useful to explain your position and why Roon doesn’t support UPnP protocol.

PS: In the LMS (ex Logitech) environment plugins are available to use LMS server with UPnP and Chromecast audio endpoints: https://github.com/philippe44/LMS-to-uPnP and https://github.com/philippe44/LMS-to-Cast

While Roon emulate LMS (working very well) i’m curious if someone use these “bridges” to stream from Roon (with SqueezeBox support enabled) to UPNP renderers, even if the UX is not as good as with true native RoonReady devices ?

1 Like
8

While Roon emulate LMS (working very well) i’m curious if someone use these “bridges” to stream from Roon (with SqueezeBox support enabled) to UPNP renderers, even if the UX is not as good as with true native RoonReady devices ?

We’ve thought about it…it’s very difficult to get that right.

Many of the other apps that “support” UPnP as a backend do it by simply shipping media files over to the renderer (meaning: only files supported by the renderer can play). This approach violates some of our basic principles like “all media should be playable on all endpoints”, so we’ve never treated it as a real option.

That would leave us doing hacks like generating an infinite length .wav file on the fly, sticking our audio stream in there, playing the fake file on the device, then trying to push the “play” and “stop” and “pause” buttons at the right times to make everything work.

I call this “transport on top of transport”–since you have two sets of transport buttons in the system, and one is sort of slaved to the other.

We went through a similar exercise with HQPlayer. In that case, we had the help of the developer, and we only had to make Roon work with one implementation. Getting it all to work reliably was an extended and frustrating process, and we ended up needing to make modifications to both Roon and HQPlayer before we were done.

Squeezebox was somewhat complicated too (for different reasons), but you can buy enough hardware to test all of the cases for about $300 on eBay, and it’s a relatively stale ecosystem, so we don’t have to worry about stuff changing out from under us. And that’s why we did it, and why we are not having a huge problem supporting it.

I expect UPnP to be much worse–it’s an old and inconsistently implemented standard. We know that devices behave differently from one to the next. And we don’t have a way to obtain the huge variety of UPnP devices out there–so our ability to support that product would be near-zero.

So on the whole, even if we expended the technical effort, I have my doubts that we could ever get to a place where we confidently say “We support UPnP” and our users can confidently buy UPnP stuff and know that it will work. And lots and lots of time will go down to toilet getting from where we are to that (disappointing) final outcome.

I never say never…but I don’t want to push out bad product, or product we can’t support well. And I haven’t seen a way around these issues yet.

1 Like
9

Thanks very much for the explanation, Brian.

I suspect this will sound very self-interested, but is there any chance of supporting OpenHome? In my experience, multi-room and multi-remote sync does work reliably with multiple Linn devices, and I understand (but don’t have first hand experience) that this remains true when other OpenHome hardware, such as Aries and Lumin renderers, is added to the mix. I realize this would not open as big a market as generic UPNP support would, but it would make Roon a great option for the highly motivated Linn user base, in addition to users of other OpenHome-compatible devices.

Over at the Linn forum, I’ve also been advocating for RAAT support in Linn devices, but anything that could be done from Roon’s side would also be greatly appreciated. I believe there is a natural crossover between Linn and Roon users, but using AirPlay into the Linn devices just doesn’t sound as good as good as Roon or Linn should.

10

Pretty much everything I said above applies to OpenHome too. Format support is determined by the endpoint, and we’d be still be doing “transport on top of a transport”, just as with UPnP.

The main difference with OpenHome is that the field of devices that support OpenHome is smaller and less varied than UPnP and we have a reasonable chance of getting our hands on a representative sample and supporting them well. The importance of this shouldn’t be understated–it makes OpenHome a much more realistic possibility.

As far as the other stuff goes, OpenHome and UPnP are nearly indistinguishable in terms of technical challenges. This is to be expected–OpenHome is basically just UPnP AV done better. The architecture is very similar.

As far as multi-zone sync goes… I don’t think zone linking (or the lack thereof) is really going to sway our decisions. We support playback mechanisms with and without it today. I brought that up to shed light on the fact that within the world of UPnP, there are (at least) three playback mechanisms to support (AV 1.0, AV 2.0, and OpenHome), and that they aren’t consistently interoperable with each other.

(There is also the Songcast protocol–which we could theoretically speak directly without the compromise of using a virtual sound card. I think it has a stigma in the Linn community because it is mostly known to people as a virtual sound card app, but architecturally that protocol is a much better fit for us).

1 Like
11

Brian, thanks for the very quick response. It’s a real pleasure to see the Roon team’s involvement on the forum and I am continually impressed not just with the team’s responsiveness, but also with the substance of the responses.

I understand that OpenHome support would be a kludge, and my first preference would still be to persuade Linn to support RAAT. I’ve made some efforts to this end over on Linn’s forum, but unfortunately have not yet seen a similar level or responsiveness on this topic on that forum.

In any event, if SongCast support could be baked into Roon any time in the foreseeable future, that would of course be hugely welcome! I’m not sure there’s much of anything I can do to help, but if you ever need beta testers, please don’t hesitate to ask.

12

16 posts were split to a new topic: Using Roon with the LMS-to-uPnP project

20

Not defending UPnP, but that’s not really true. With MinimServer/Streamer, transcoding is built-in and many users of Minim transcode to WAV/24 for both compatibility and SQ reasons.

With Twonky, in the very bad old days of UPnP, much of what you describe was the case, but Minim has really become the de facto standard for UPnP servers and is a really nice solution when coupled with a good control point like Linn Kazoo or BubbleUPnP.

Oh, and those control points all support toggling between a consuming and non-consuming playback queue, so there’s that part :wink:

21

Which was why it was such a brilliant choice of word, Twonky being famously wonky, so emphasising Herold’s point. It was positively poetic.

1 Like
22

HQPlayer use NAA together with MicroRendu. Roon use RAAT. Could HQPlayer in theory use the RAAT or Roon bridge instead or in addition to NAA. If yes, would there be any benefits, like possible more stable communication?

Could any SW player/render if they like, use RAAT or Roon bridge as an option to other standards ?

23

No, because HQPlayer doesn’t know how to talk to RAAT, and the protocol itself is not open.

The “right way” to accomplish that goal would be for HQPlayer to expose their DSP functionality in a “loopback” fashion to Roon, so we could pump audio through their engine and then distribute it.

A benefit from this arrangement would be the potential for synchronized multi-room playback. Another would be support for RAAT’s support for remote-control of hardware volume control, convenience switching, etc.

I don’t have enough experience with NAA to comment on stability. I think we may have done some more work to make WiFi streaming stable, which is less of a focus for HQPlayer, but really not sure under what conditions you’d notice a difference.

24

You may have a quick look here:
http://www.computeraudiophile.com/f11-software/hq-player-20293/index263.html#post586743

Apart from his invitation which I guess you better talk about together outside the forum, is it correct that multirom functionallity may degenerate the SQ ?

I guess yes, as there can only be one master clock, and that master should be the DAC ? Or ?

25

Yeah, that’s an inescapable engineering reality–there can only be one master clock during playback, and most devices don’t provide a way to make slight adjustments to their clock frequency, so during multi-zone RAAT playback, we choose one of the endpoints to be the master and the others must make adjustments to conform to it to it.

That fact that this reality exists doesn’t constitute an argument for or against this sort of integration, in my view. It’s just a fact of life that must be dealt with to engineer a multi-zone playback system that doesn’t support flexible clocking at the slaved endpoints.

My guess is: were this to happen, it would be because we expose an interface for DSP plugins, and HQPlayer slides into it. I don’t see any fundamental conflicts with this model. That said, in our view–HQPlayer’s primary value is in the DSP, not in its audio distribution support. Jussi’s point is that HQPlayer is actually both things, and I understand why that’s important to him. And I understand why you might want to combine his DSP with our audio distribution. I would like to see that sort of interoperability made possible in the future.

2 Likes
26

12 posts were split to a new topic: User Selection of the Master Clock in Grouped RAAT Zones

27

Is this still a valid scenario? I see that I can group two zones and apply DSP like upsampling on one of them, but not the other. Volume Leveling seem to be disabled in this scenario though.

Have the changes in RAAT made clock sync irrelevant or does Roon still sync the simulstreams?