As long as you turn OFF any logitech servers on your network, you can turn on squeezebox support in roon and any devices on the network will show.
I have never used UPNP for music delivery so cannot comment on the differences. But roon sounds good to me.
It would good if was part of the ROCK build for NUCs & the Nucleus products, in the same way that Roon has Squeezebox support, to internalise the UPnP Bridge.
Will never happen. The CTO has stated his views and disgust with UPnP not from sq perspective but everything else it’s does or doesn’t do.
And CG that is the rub… the CTO states on his forum his dislike for something open and published, but doesn’t share in a meaningful way what he does… sure consistency is achieved in a locked down closed system…but credibility is lost if you criticise and then don’t openly share to counter… it’s easy to knock. His approach also stifles innovation, and ultimately may lead to a less than optimum outcome.
I think UPnP Media control is a good consumer standard, and then it is ratified by industry profiling groups such as DLNA… it allows diversity and differentiation giving maximum consumer choice whilst offering a high degree of (but not 100%) interoperability.
There is much mis understanding about UPnP DLNA… it’s not an application end user standard, it’s an API of service libraries… as such there will be great variation from different vendors so as to provide maximum consumer choice… and you can argue that it is that that has allowed to become ubiquitous.
From a SQ perspective, UPnP’s media transfer simplicity also allows maximum SQ to be achieved though manufacturer end point innovation. I am sure that is why Naim and Linn focus on it and build upon it to suit their ecosystems.
If I am honest this CTO’s view is putting me off subscribing…I like to know what I am buying, warts and all and then make an informed choice…
Sure as I said elsewhere I will now reverse engineer through my engineering curiosity and also to share … but should I need to?
I guess this is your desire to understand the workings. All I want to know is does it work. It does for me but I did not purchase because of sound quality I bought because of how easy integration with so many devices is.
That being said there is no access outside my network which is a shame
2 Likes
Hmm, I wonder if this has something to do with the fact that JRiver and Roon also sound clearly different. Both configured to use WASAPI bitperfect output with as similar settings as possible but still, clear difference in SQ. Though I’ve only compared them with my PC connected through USB cable to USB-bridge and from there with BNC-cable to Naim DAC. It’s difficult to say which one sounds better, it depends on rest of the setup. At one point I preferred JRiver but nowadays Roon has slight edge IMO.
1 Like
Couldn’t agree more with your point about the virtues of open standards (if I may paraphrase) Simon. The trick with Roon is the absolute loveliness of the user interface. I would have been very happy with the Roon interface on top of my prior MinimServer setup, and I get frustrated with metadata in Roon every time it doesn’t work automatically (which it usually does).
As to SQ differences between Roon and UPnP, I’m blessed with inadequate hearing since I can’t discern any at all, and I’ll say that Roon crashes far less often (not at all actually) than MinimServer did. So maybe their implementation is better… if only we knew why!
Look forward to seeing what you come up with once you get your test equipment setup and do a little reverse engineering!
2 Likes
Open standards does not always equate to better. Reading Rooms CTOs thread on why he dislikes UPnP he hit the nail on the head for me, as he highlights it’s shortcoming’s that I experienced with it. Trying to have a multiroom setup with different endpoints from different manufacturers was a nightmare and never worked. The fact that the new Naim stuff is not compatible with other control points for gapless is just unforgivable in this day and age. No gapless should be a thing of the past but it’s never implemented well across all devices. Mostnof the free control point software are also gash. You have to pay for something like jriver or Audiovarna to get a half decent experience and then they have limitations.
Also Has Apple ever divulged how Airplay worked at all. I don’t care if I don’t know the inner workings of if they don’t put it on display for all to tear apart. I just want something that works, sounds great and gives me the best user experience. For me nothing has come close to this until Roon. Is it perfect no but it’s developing all the time and offers user created plugins, if that’s not innovation then what is. Has UPnP evolved or can to add new functionality in this way?
4 Likes
I agree with your approach @CrystalGipsy. In the world of trade-offs, trading “it doesn’t work on all of my devices” for “it’s an open technology so the free market can adopt and innovate and build all sorts of devices” is a poor trade-off when it comes to my in-home music network working.
And I’m sure it serves Roon’s business objectives - which include supplying technology that works - to have not positioned themselves as a ‘better solution to UPnP.’ I don’t feel it was a wrong approach on their part, evinced at least in part by their ability to reach key manufacturers and get their technology adopted!
For discussion: Maybe Naim are better off selling “Roon-ready” devices that their customers use with Roon and thus WORK WELL and RELIABLY, vs. the faffery of the last 5-6 or whatever years of customer after customer reporting that they “can’t get the Naim App to work.” My wife is a prime example - she thought I was insane for spending so much money on hi fi where we couldn’t reliably play music. Now myself - I got my home network well-sorted and it was working well on the Naim App, but its MORE reliable on Roon AND the interface is more liked at home . . . and it does not sound worse (or frankly, different) to either of us.
2 Likes
Interesting thoughts, but RAAT is more demanding on the underlying network for media transfer than UPnP… my point about open standards encourage innovation, which is why many of us professional engineers recommend them.
It’s true in consumer land where a certain level of mystique is often required to create a marketing differentiation there is not a great benefit in true open standards … I guess this is the difference between real engineering and consumer marketing productisation.
One reason I choose Naim is that they tend to focus more on the former… and they have optimised their platforms for best SQ using UPnP media transfers… but yes they support Spotify, Airplay, Roon etc for consumer appeal… but at an impact in absolute SQ when using these service features.
To me it’s a shame the usability of Roon is let down by the impact of SQ on higher end Naim equipment… so now I am tending to use Roon like Tidal for discovery, and it’s really great for that via its application… for immersive listening however,… ABSOLUTELY UPnP …
1 Like
I’ve worked quite extensively with UPnP for audio applications… including my own implementations of the standard. I’ve no idea what this “CTO” has said, but UPnP is a pretty poor standard that has lead to many vendors leveraging incompatible specialisations - I suppose in the name of “extensibility”. I think I could forgive someone for thinking they can do a lot better.
I also have extensive experience with UPnP in usage, debugging and development… and hence I am aware it’s about a set of API libraries rather than user applications… and yes it has limitations, which in part are imposed by simplifications for working across of variety of different consumer network qualities…
It’s not difficult to improve on certain aspects of UPnP for specific use cases… and some take the UPnP API Core and build an effective application ecosystem on it… Sonos is a great example of this with a robust successful consumer product powered by UPnP. … but I can’t see how you credibly differentiate your proprietry approach to a published specification, especially when quite critical of it when you are not saying how you are different. If you refer to differences at an application level you have completely missed the point… and yes there are some UPnP extensions such as the API support for gapless that are not fully ratified… and Naim are aware of this… so you compensate an an application level.
Again Sonos do this very well, and most consumers wouldn’t even know they were using UPnP libraries I suspect when using Sonos.
SQ is very much part of the Roon ethos otherwise they would not have so much focus on the signal path being evident and they take support requests in this regard pretty seriously. Others don’t report the differences you do, whislt others do and this can go either way as to which they prefer as is evident in this thread. As we all know its a very subjective subject and hard to actually say what is right and is likely system dependent or one piece in the chain that works better in tandem with another. Bart for one has the top line streamer and has no qualms with the SQ.
To you it’s obvious what you prefer and that is fine but you can’t question Roons philosophy on SQ because of it. Perhaps for one moment Naim have got something wrong and not implemented RAAT to the best of their ability ? Perhaps it’s missing out a piece of the chain they left in for UPnP? This itself can lead to innovation to get over these hurdles as yes Roon is more network heavy but it’s also very young (if you don’t count sooloos for Meridian) compared to UPnP aandhow long as it taken to optimise for that? It’s heavy for reasons they clearly lay out in the RAAT kB on their site. It’s this that gives it such better leverage as a user experience as it offers so much more control and functionality. Does this come at a cost of SQ or is it something else or just in the ether and bias we all have.
All good points… but I have no axe to grind… although I am aware of my unconscious bias against closed systems, no doubt because of my professional life.
However when I relax I like to enjoy the most immersive listening experience I can get… it’s very important for me, no doubt why I have invested no small sum in my Naim and other equipment. When I find something that affects that I want to know why… I like the usability of Roon, I like it a lot. I had discussion over a period of time with Naim in the optimisation of some of their new architectures to improve SQ with Ethernet based media transfers… and I even freely shared some of my own findings and I am now enjoying the benefit of that with my new NDX2 transport.
So when I find when using Roon it doesn’t give me the SQ performance I can otherwise get given Naim’s optimisations when using UPnP … I want to know why, I guess that is the engineer in me … and that is where I am…
When it comes to SQ performance I rank Naim up there as one of the leaders…
… and to be clear I don’t want to over state this difference … I find the SQ impact of RAAT over UPnP media transfer very subtle… and on certain recordings it’s more noticeable than others…
I would raise it on Roons forum and ask the CTO to comment as it should be every bit as good and if you feel its not then its worth mentioning, they are open to ideas and insight from others and as you are very adept and capable technically from an engineering point would be able to put across properly and likely listened to., Quite a few members have added quite significantly to this from the forum especially with SQ as they revealed some issues with DSP side they are looking at and other shortcomings. Its not a closed shop even if it doesnt support UPnP.
1 Like
“Others” including possibly Rob Watts, designer of the Hugo many here prefer to even the NDX 2… I seem to remember Rob being on the record saying it doesn’t really matter how you feed his DACs, they account for transport errors such that even a “wet string” would do!
1 Like
I think you might be mis quoting, or mis representing or taking out of context what Rob might have said… I have discussed such things with him personally, and he and I, as well as Naim designers, absolutely understand and value the importance of the transport and consequently he has created a new product and enhancements to improve transport performance amongst other things as seen by the DAC.
Oh please read earlier on in this thread… Chris, valued member of this forum has possibly noticed a difference like me… I value Chris’s judgement and if he says something I wouldn’t be inclined to dismiss it… you may find Naim users are a little more discerning that some others…
Ouch. Mis representing… sounds like you’re questioning my honesty. I’m sure you don’t mean that!
I think we’ve all seen the wet string quote over on that other forum. Unfortunately it’s been re-quoted so many times, that the original is a bit hard to find.
Anyway, I wasn’t stating my opinion, since I don’t have a Chord Dac. Only pointing out that it’s ironic the designer of many denizens of this forum’s favorite DAC can’t hear the differences in transports, (or USB cables in another quote), that many fans of his work swear by.
I always assumed this was why Chord didn’t bother making a transport for Dave or Hugo: because a Raspberry Pi would do in their mind.
Hi, no not questioning your honesty at all , just perhaps your interpretation of what he may have said 
If you ever get the chance Rob is an interesting person to discuss things with, especially if you are more technically inclined in this area… and that goes for technical discussions with some of the Naim designers as well.
Being a Chord DAC user I can indeed confirm the end result achieved depends on the quality of transport… just see my comments about the NDX2 and the NDX before that 
I think most of us are quite discerning with regard the end result Simon, whether Naim users or not…
This thread seems to have drifted off somewhat so I’m looking forward to what your wireshark logging finds. I’m also curious as to whether you find the same differences between UPnP and RAAT when using the NDX2 as a transport (I’m not clear whether you were still using the Hugo with your new setup) rather than the NDX2 internal DAC.
James