Considering the functionalities RAAT offers it seems obvious that it is more complex then UPnP and therefore potentially generates more traffic (which means more hardware load).
The question is : do we need/want such a protocol? Considering the success of some protocols like RAVENNA (Pro) or RAAT (consumer), the answer seems to be yes.
Well then. But are the ideas behind RAAT well implemented? It’s a closed protocol… Let’s suppose that inside is state-of-the-art code.
What could be done, in the context of audio, to eliminate the impact of traffic heavy protocols?
The answer is also quite obvious: the hardware needs to consistent with load needy protocols.
Finally, the real question isn’t : does UPnP sound better than RAAT?
The real question is : are the new streamers consistent with the load requirements of protocols like RAAT?
Considering that some of us seem to hear a difference in SQ in favour of UPnP, it seems that the new streamers are not correctly designed to be used with Roon like software.
That’s more or less what Rob said to me when I met him. He also advised any decent USB cable would be fine. I took his advice and also put his recommended split core ferrites on my Canare coaxial cables. I use µRendu to feed it, but have tried other transports and I couldn’t hear any difference at all. I tried Roon, but disliked its user interface (can’t stand music reviews). I couldn’t hear any difference in sound quality. So I’m more than happy to select an album with Kazoo and just listen to the music.
I would like a nicer built universal transport (no DAC) than µRendu with room correction built in. Mac mini works well enough, but looks a bit odd in my Fraim. If Naim makes one in the future at a sensible price, I’ll try it.
Yes if we start bucketing contributors into those who can hear the difference between USB cables, or RAAT vs UPnP, or the effect of blue marker pen on cd’s, it’ll take us where we don’t want to go. And I know @Simon-in-Suffolk doesn’t intend that.
I am heartened by two facts – the Roon team come from decent hi fi roots, and they are quite responsive based on my reading of their message board (which uses the same platform we’re using here now!).
I have no doubt that it will always be the case that some people can hear some difference in something . . . that “mere fact” doesn’t sway me one way or the other, with cables, Roon, or my green Sharpie.
What if I said that considering some of us seem to hear a difference in SQ among ethernet cables, Naim products are not correctly designed to be used with ethernet cables?
And Simon, G_d love him, hears differences among UPnP implementations. Perhaps Naim have ‘screwed up’ there ?
The uptake on devices using RAAT and being Roon Ready is increasing, especially in the high end. So as it becomes more of the norm, then I can see innovation moving to improve performance for it. If the weak link is network load causing SQ differences on the devices themselves then engineers need to work away past this like they have done for UPnP. Things are not going to stand still forever, we will demand and want more features and functionality without a loss of quality and network loads will increase.
Would love the chance to chat with Rob and/or the folks at Naim. Last time I was in the UK, I tried to swing by the mothership in Salisbury for a tour at your recommendation, but they where overwhelmed with the roll-out of the Uniti range and not taking visitors. Should have another trip to the UK in the works this year, so will try again.
The Ethernet parallel would be fair if Naim did sell Ethernet cables, not optimized for their streamers
My point is that, in the context of a relatively expensive streamer, sold as “Roon Ready”, UPnP and RAAT should sound the same. In other words the hardware should handle the load RAAT generates without being affected.
Not sure about this argument… let’s say you’re streaming 24 bits at 96 kHz, that’s about a 4.4 megabits per sec (Mbps) data rate (96kHz * 24 bits per sample * 2 channels)/(1024 bits per kilobit * 1024 kilobits per megabit). According to the Roon CTO: “There’s some minor overhead for packet headers.” Hard to quantify “minor” but let’s agree that it’s less than 10% of the data rate. So somewhere below 5 Mbps total.
Over ethernet cable? Not very taxing to any network built since the turn of the millennium! Roon does add some overhead, and that may be greater than UPnP, but neither is a very large difference as a percentage of the base data rate. Either way you’re talking single-digit megabits on hard-wired networks designed to comfortably handle gigabits! 10 Gbps or 10,240 Mbps on Cat 6 with the right hardware. Our audio isn’t even using 0.5% of what a modern network can handle…
Of course if you’re going wireless it’s an entirely different question. And there may be other arguments for why transport and protocol may matter. But I struggle to believe how RAAT vs UPnP overhead on the base data rate could be a factor for anyone using a tethered network connection. But if you’re worried, or OCD (as I suspect many of us are - myself included), just configure your router to prioritize traffic between your NAS or Roon core and your transport.
Sorry more precise would be UPnP network traffic not UPnP itself. I am goingn off Simon’s quote about Naims effort in the new lineup further up the thread. I’m suggesting that maybe further improvements are needed for RAAT as it’s heavier then UPnP and could in theory be creating the noise and difference some hear. I take it this is what Simon’s theory is for the difference? Or I could be misunderstanding here.
Perhaps completely isolating transfer from DAC is the answer? Be interesting to hear if Simon still hears the differences when using the Chord DAC and the ndx2 as transport only.
Yes we do… the transfers occur as rapidly as possible now rather than start/stop window sizing of the earlier architecture, resulting in less tcp processing and lower digital noise.
We can hear the effects for example of tcp processing when we use a media transfer proxy compared to not using one for Tidal in the first gen architecture
@Simon-in-Suffolk: Do you think an optimization, or even better a partial rewriting, of the new streamer’s Roon implementation is something that could done in order to better S.Q.? Or is that lost cause?
I’m aware of what Naim have done very recently with the new streamers (although as an amateur, I won’t pretend that I fully understand any of this!) What I was trying to grapple with is whether or not the UPnP protocol itself has evolved in a way that might improve sound quality over its lifespan. If it’s a relatively old protocol, has it, in itself, as opposed to Naim’s implementation, matured and improved, and could RAAT hypothetically do the same?
I await with interest your explanation of how I am missing the point
RAAT is constantly being uptomised and updated it won’t stand still, not sure about UPnP, from what I have read nothings changed much since 2008. That is an Eeon in the tech world. OpenHome is a subset of UPnP that added and improved it from a user perspective, better gapless, multiroom and playlists being on server, not the endpoint and adding streaming services, but I don’t think anything so been done from an SQ perspective, that’s in the hands of the endpoint devices… But happy to be corrected if wrong though.
Before I recently purchased a lifetime license for roon, I did a blind test of my system with several people to see if there was any difference in sound quality. I used to listen to music directly from my QNAP NAS over the network with Asset UPnP. New I also installed roon on the NAS and use the same way, but with the RAAT protocol. The result: nobody could hear a difference!
Would this mean there was a difference in sound quality between WAV & FLAC? Surely best to use smallest possible FLAC files across the network. If there is then I can’t hear it and as far as I can tell my DAC gets the same data in its buffer from WAV and FLAC (irrespective of compression level). Similarly I can hear no difference between media servers. I feel sound differences if they exist are inconsequential compared with other parts of the audio chain such as loudspeakers.
When I hear this networking saga, I should really stay in the corner, out of the spotlight, listening to my music, but I’m trying to keep up and I don’t know if I can do it. Oh no, I’ve said too much. So does anybody use Linear Solutions audiophile routers and switches from the same company that brought you music servers with a proprietary time perfect OS because they know an operating system is as important as any critical component so they went through all the OSs available but were unable to find one that could provide great sound. Thus Dream OS was born. Dream OS uses time accuracy to reduce latency on IO, Processor and OS. Hence the impressive sound reproduction.
If only they would enable me to disable reviews & suggestions then I’d give it another go, but I found its metadata overload more than irritating. Do you think this might be a possible enhancement they’d consider?
The pro-WAV argument that has been expressed here is that because Naim streamers are designed around WAV, the DSP has a higher workload if it has to process FLACs, which might produce more electrical noise.
The idea that the data transfer rate across the network might also be a consideration is a separate matter, only raised more recently. At least, that is my understanding of this.
