I’m inclined to agree with you, there are only so many swathes of metadata, reviews and recommendations one can absorb before it distracts you from the enjoyment of the actual music, and I tend to find the Naim app to be ‘enough’.
Having said that, it takes quite some time to find your way around Roon because it can do so much. I suspect that once familiar with the interface, it becomes more comfortable to use for most people.
Hi Chris, no not that I am aware of… and essentially UPnP is largely about control… when media is being transferred there is nothing specific about UPnP, it’s essential a transport stream of data … ie media data that is transferred as fast as the server can send and the receiver receive… when the receiver is full, it tells the server to stop until it’s ready again. This transfer uses Transport Control Protocol … which is what a significant proportion of all non ultra low latency unicast network traffic uses everywhere… and allows the data to flow reliably between two specific hosts.
So if the server can quickly send, and the receiver can as quickly receive and store the collected data (ie large sample buffer) over a reliable link such that data is in order and not lost, which typically a home network provides, the TCP is working optimally with least interaction and therefore the most efficient… this equals lower digital noise from digital state machine processing… this is essentially part of the approach Naim has taken with their new architecture.
Thank you Chris
So it is swings and roundabouts. My guess is if Naim made a universal transport then FLAC vs WAV would not be an issue, but when it is Naim’s FLAC/WAV processing is within the same box as the DAC then it’s different. That assumes Naim’s software extracts the same music data content from both formats. I can see it is harder to extract from compressed FLAC than WAV.
I would not expect a Naim transport to sound better than what I have now, but its value would be in better build and ease of use. If it had digital room correction then it definitely would have potential to perform better than my µRendu. I know there are boxes that do this already, but they are not made in the UK or easy to audition.
Post your suggestion to them! The ability to “turn off” the ‘review’ info in the interface is worth asking for. People who like to read the info might actually like to turn it off to un-clutter the interface.
1 Like
I’m not sure if Naim could produce a ‘format agnostic’ streamer - perhaps other brands are? I suspect that their answer would be that their own servers and streamers are optimised to work together with WAV, and even if you prefer to store in FLAC, there are servers that will transcode to WAV on playback, so there are plenty of options available.
1 Like
Cant say I think it’s cluttered myself, but everyone to their own. Its the recommendations of my own music and reviews that I love. Use those features a lot for.discovering lost gems in my own collection and finding new music by following the breadcrumbs to other albums by same artist and offshoots from collaborators etc. Takes me on some wild musical journeys. It’s what keeps me hooked.
UI is due a refresh and from rumours is being worked on. So maybe put in your tuppence.
Well, maybe, but of course this (as well as the above point about data rates) presupposes that transports don’t buffer, when we all know they do. And DACs buffer again after FLAC decompression.
There’s an argument that can be made, that both buffering (with its implicit error correction) and the conversion, stresses the power supply differently for different implementations (e.g. Wave vs FLAC) and this power supply modulation is audible. My instinct is to say that the variation in power supply draw must be so small relative to the overall power consumption, and the power supply so over-engineered (particularly with Naim), that this is a non-issue. But I haven’t measured it, or heard it, and others say they have.
Not familiar with Linear Solutions, but as a UNIX user, I wouldn’t be surprised if their time perfect OS was nothing more than a pared down Linux implementation like DietPi and many others. Again, for this to be audible, would depend on the power supply modulation argument above. Not sure I buy it. Not sure I couldn’t design a buffer and data-converted that drew constant power regardless of whether it was working and eliminate power supply modulation effects.
At some point I start to think some of this is marketing drivel preying on the non-technical audio enthusiast. Then again a Bose fan might walk into my house, see my $40k Naim and Focal setup, and think I’m an idiot…
2 Likes
And while you’re at it you could consider asking Toyota to remove the electric engine from their Prius as an enhancement?
.sjb
3 Likes
Ok looked at the data on the line… not much difference or any meaningful difference between UPnP media transfer or RAAT media transfer… the only difference I could see which is most likely source host related was that the UPnP media transfer used smaller TCP window sizing than the RAAT TCP window sizing… which would mean there is actually more overhead with UPnP than RAAT in my setup… so perhaps my perceived differences lie elesewhere.
2 Likes
Thanks Simon - Is there a burst of network activity as a track starts to play on the NDX2 as the buffer fills and then settles to nominal (in UPnP mode) ?.
Apologies if i missed the reply further up the thread but do you find the differences between RAAT and UPnP with the NDX2 just acting as a transport ?
James
James as a transport… the flows looked quite consistent say over the first 30 seconds or so… and not bursty within a few segments like the first gen Naim streamers.
Looking at network activity when streaming to my Atom, I noticed that you can see a burst of data filling the 50MB buffer at the start of each track, followed by a steady flow of data until the full track was loaded. The NDX shows a much smaller burst as its small buffer fills, followed by a longer period of steady flow as the rest of the track loads. No doubt a less sophisticated investigation than Simon’s, but it was interesting to see the differences.
For what it’s worth, here’s a graph showing network activity during regular 16/44 UPnP streaming to NDX:
…and to Atom:
My interpretation, correct me if I’m wrong, is that the NDX is still loading a steady amount of data until almost the end of the track, i.e. it’s only just keeping up. The Atom, by comparison, can load a short track straight into the buffer in one go. The first track you can see is longer, so the buffer continues to get topped up for a while.
depending on the rate of data transfer from the server, the NDX will either progressively and consistently transfer the data - or if from a higher speed server - as per most NAS or home lan media servers, you will see the PDU transfer made up of a bust of data until the NDX TCP window buffer is full - and then the NDX stops the flow but zeroing the window size - until the TCP window buffer empties somewhat and the NDX then invites the media server to resume the flow of the PDU by opening up the window size again - and this repeats until the the complete media PDU is transferred - hence the bursty flow of data.
It is this behaviour that determines the processing overhead per amount of transferred media data - rather than the amount of data itself. You need to look at the TCP packets rather than the raw data flow. A tool like Wireshark will allow you to do this - connect a managed switch to span the port going to the NDX and feed that spanning session to your Wireshark investigation ethernet port - and you will then see this playout. This is how Naim have measured and assessed as well when we were comparing traces some time back when the new streamers were in development.
Simon, the graph I posted above looks to me like a ‘burst’ as the buffer fills, which is the whole track, or the first 50MB, loading in the first couple of seconds. Not sure I understand how that relates to your 30 secs of consistent flow?
Why would I do that? My Toyota (how did you know I had one?) lets me drive using petrol or electric so I have the choice. I choose to use mostly electric because it is cleaner and cheaper. I get about 200 miles for a gallon of petrol. So I’m a bit lost on what you’re saying.
I’m not saying Roon should not include reviews and suggestions for those that like such things. I am saying it should have an option not to display them for folk like myself who dislike reviews and don’t want the suggestions.
I know its has become fashionable to ask people what they want and then set about doing the opposite, but I’m old fashioned enough to think choice is a positive rather than a negative.
Looking at Roon’s forum there are lots of customers or potential customers who would welcome this feature. If they would like me to become a subscriber then this option is essential as I dislike All Music’s reviews, if they would sooner not have the likes of me, who knows what I like in my wardrobe, then fair enough. I have written to ask if it’s possible, but no reply thus far. I like Roon showing who wrote the songs, who plays what and lyrics, but abhor reviews.
Apologies to OP as this is off thread.
1 Like
Hi all,
I’m curious about the sq differences between room and upnp. For what it’s worth I have roonified my nd5 xs, not by adding a dac, but by using an LMS (Logitech media server) to upnp bridge. I enable LMS mode in the roon server and can play to the nd5 xs from the roon interface. Awesome! I expect that since the streamer still gets upnp delivered music the sq is preserved. The software lms-upnp bridge is opensource and on GitHub search for philippe44 lms-to-upnp. Interested to hear if anybody else has gone this route?
Cam
Without looking at your TCP flow you can’t equate one with the other… but the bandwidth from your media server becomes a variable
Yes, but with the Sonore UPnP Bridge, essentially the same concept, but packaged with the SonicorbiterOS, so less DIY 
Used for about a year with an NDS to make this ‘Roon Ready’.
As you are feeding the NDS from the Ethernet port, with a UPnP protocol based flow, there is no format conversion to S/PDIF, as well as using the optimised path in Naim’s Classic Network players.
1 Like