Firstly, thanks you to everyone for your input - much of it over my head and all of it much appreciated!
The opinions seem to me to be:
I imagine the difference or my perception is skewed by different volumes. After careful consideration, experimentation and comparison I don’t believe this. The exact same Qobuz stream sounds less good to me when I listen to it via Roon>EVO than when I listen to it direct to my EVO. It is still very good but it is as if a thin veil is over it: I don’t believe the EVO is tarting it up with some ‘warm up’ process because it doesn’t sound more warm or deep or lush, it just sounds cleaner, clearer and more transparent.
There’s actually something going on in the process that means that the same file sounds different when it goes through the two slightly different processes. I’m not an engineer so I can’t test this or even really understand the various hypotheses as to what it might be that causes it but I am sure it’s there. It might be specific to the EVO but there are other reports out there across a range of equipment that make me suspect that something is going on here.
It’s not a deal breaker, really - for causal listening and on all my other end-points it’s not an issue at all and if I really want the best SQ I can squeeze from my system I can just switch to the Qobuz direct to EVO combo knowing that I’m really lucky to have anything that sounds this good. But most of the time I’ll probably stick with Roon because of the discovery features and because of the way it rounds up all my disparate end points and points them in the same direction.
It is bit perfect no arguments as my DAC tells me so when I send RME bit test files to my RME DAC via RAAT and Roon. Wifi or Wired network do not change this nor does decoding to PCM. MQA would not work via Roon if it wasn’t bit perfect either and it does,
Roon actually shows what is going on quite nicely in the signal path display.
RAAT (barring some new and unusual bugs) is bit-perfect in a sense that unless you do some processing your device gets exactly the data that is in the source.
With something like MQA (without even going into discussion whether MQA is good or bad), if you set Roon to do initial unfold in the core, it’s not strictly bit-perfect – data sent to the DAC is different from data that arrived to Roon (although that process is supposed to be deterministic). Of course if you do all of MQA processing in the DAC, it’s not bit perfect in the sense that bits sent in for conversion to analog are not the same as bits received from the source, but even here results should be identical regardless of what the source is.
As for RAAT being (or not) bit-perfect, it’s pretty easy to check and I believe people did test it and found exact same data coming out as what was going in.
WiFi would not be a factor here, all issues in transmission are handled at the network layer; you may get dropouts, which would be quite obvious, but if you get data, you get exact same data, there is nothing that could make SQ different.
I can only add this observation. As a beta tester for a prominent high end company that was building its own playback software (before ROON) the other Beta testers and I found sound quality differences between different versions of the playback software. The software was written to be bit perfect. Volume and settings were all kept the same. The only difference (for example) was between Build 30 and Build 31. Sometimes the the builds were identical sonically but sometimes the high frequencies might sound different or the bass, imaging, etc. We were told the differences were caused by using different compilers, software jitter, and how much strain the program put on the CPU.
In many instances not much difference could be heard. But if new features were added that paled in comparison to what ROON accomplishes there were almost always differences in the sound quality between the two versions. In fact we were encouraged to keep each new build on our PCs so we could compare builds and give feedback.
For the reasons above I would not rule out differences in sound quality between ROON versions.
In my opinion the biggest culprit causing the differences in sound quality was almost always after new features that were added. These new features would directly add to the “strain” on the CPU. After the new features were added it might take a couple of new versions to bring back the quality of sound before the new features were added. Unfortunately we were not told what the cause of these deferences were.
Thank you Steven. I am quite certain that there is a difference and this sounds like a perfectly possible explanation. As a footnote I have been using Chromecast from Qobuz on my tablet to the Chromecast Built In feature of the EVO and it sounds to my ears identical to that achieved by using the EVO’s Quboz feature directly - as it should. So Chromecast also sounds better to me than ROON.
You didn’t understand what I said. It’s not a question of bits, but of the timing of the electrical encoding of those bits on the I2S connection to the DAC inside the streamer, which could easily be affected by slight differences in how the I2S device driver interacts with the rest of the streamer’s firmware, even when all the bits are correctly output. As for “in any competently designed system” I have bad news for you: in five decades working on digital stuff, even the most competent, top-notch hardware and software engineers I’ve worked with could not fully avoid shipping concurrency and timing bugs in their products. As Dave Winer famously said: “We make sh*tty software … with bugs!” And equally buggy hardware.
Bugs happen, for sure, I’ve shipped my fair share of them. Well-designed DACs (maybe not “audiophile” ones though) have been independent of source clock for years though. Reclocking and jitter elimination happens inside the DAC, after bits have been delivered over I2S. Maybe you can turn this off (I don’t feel like digging through ESS and AKM datasheets ) or you could supply crappy external master clock, but that just brings us back to well-designed vs. “high-end”.
You’re set-up correctly. But I think the difference is because of the demands Roon puts onto your wifi network.
The difference, assumptions being made here, is that Roon is overloading your Wifi network. Qobuz is probably sending the music stream directly to the Evo. Roon always streams from Internet to Core to Streamer. So, in your set-up you are doubling the amount of packets and traffic on your Wifi. Get the streamer or the Core or both (better) on Ethernet, even temporarily, just to test.
This is the right answer and even something like network jitter (significantly higher on wifi) can cause issues / differences with what @Fernando_Pereira says here.
Again, Roon uses double the number of packets and bandwidth on your network than Qobuz direct. Wifi doesn’t handle this well in almost all consumer networks. Switched Ethernet doesn’t care.
You should have zero dropouts. If you already have dropouts before Roon you’ll have issues with Roon.
The reason I said few if any was because it was a long story - the ending of which is that it was a matter of app switching causing what at first sight looked like a dropout. In fact there are none.
So the matter you kindly identify regarding the wifi network traffic being doubled sounds like a factor. Which makes me wonder of Roon, why buy a car that uses twice the amount of petrol despite worse performance just because it has a prettier and more informative dashboard?
Because of all the good stuff that the Roon Core can do over and above a vanilla stream from a provider. Convolution filters, PEQ etc etc.
EDIT: with your analogy, you wanted a car to go to the shops and fit your groceries in once a week; a Porsche 911 GT3 can do that, but it isn’t what it was really designed for. Same with Roon.
If you hear it nothing any of us can do to change it. On 6 years of Roon it’s always remained the same to me and sounds identical to the devices native streaming abilities. On the other hand I have found Chromecast on my Naim system to sound absolutely terrible in comparison. It’s a fine balanced act with these all in one with so many different stages to manage in small box when supporting all these different protocols and delivery methods everyone wants and keeping internal processing to the minimum and keep noise at bay. Some seem to manage it better than others it seems.
It’s a shark at the front, a hearse at the back and a banana all over. Three for the price of one. How could your wife say no?
4 Likes
AceRimmer
(Smoke me a kipper, I'll be back for breakfast!)
37
Good Lord!
Even I who have been known to drink from the fountain of excess and bad taste more times than I care to admit finds this to be beyond the pale and leaves me with more questions than answers.
Between the dodgy electrical system and the mechanical fuel pressure gauge mounted IN the passenger compartment that might be necessary at some point in time.
That’s… not how TCP/IP works. packets are buffered and original data, in correct order, is reconstructed at the network layer, long before the audio portion of the data stream is even extracted. Even if what @Fernando_Pereira says is correct (far more likely with a DAC of 1995 vintage than any current design) jitter in the WiFi signal should be about as relevant to the sound quality as the phase of the Moon.
Now, if the Qobuz->Core->Player transmission were saturating the WiFi connection, sure, that’d be bad, and possibly even audible, but it would be stuttering and interruptions, not subtle changes in SQ describable only in flowery audiophile jargon.
This is a difficult question, as there is only anecdotal evidence of what people hear and feel.
In my experience, Roon tends to sound less “alive” than direct streaming through another app. Roon sounds a bit less clear, instruments a a bit blurred in their positioning on the soundstage.
I have made this experience in various (level matched) setups:
On my dCS Rossini APEX with clock, it is easy to compare streaming via dCS Mosaic and via the Rossini’s Roon Bridge. Signal paths (and hence volume) are identical: from my NAS via Ethernet / Melco S100 to the Rossini, once using dCS Mosaic, once using Roon. The difference is clearly audible to me. For critical listening I always use Mosaic, for convenient browsing and exploring, I use Roon.
My Neukomm CDA126S DAC / Preamp is fed by a Melco N1A EX, which can be set to UPnP and Roon Bridge mode. Same difference as with the Rossini.
Using an Odroid N2 with Volumio as streamer going to the Neukomm CDA126S, same difference.
The only Roon source I have heard so far that sounded sublime was the Grimm MU1 at High End 2022 in Munich. After the excellent demo I was very surprised when Guido Tent told me the MU1 was using Roon. When I asked him about the differences I heard between native and Roon streaming in my setups, he said that Roon had some timing issues that he had to deal with specifically when designing the MU1.
This would indicate that the issue is not with Roon itself, but with the way endpoints implement and integrate the Roon Bridge functionality.
This is purely a reflection of my own observations, which may be expectation biased. No statistically significant double blind research. YMMV.
Another soundbyte: I had asked the question of differing SQ with dCS Mosaic and Roon to dCS and their response was that surveying social media gave about 50% of people preferring Mosaic and 50% preferring Roon.
When I look at your signal path I see there is no upsampling when using Roon. I believe your Cambridge supports upsampling to 384kHz. Perhaps there is upsampling to 384kHz when streaming directly and no upsampling when using Roon?
I have a Cambridge CXNv2 and this is what my signal path looks like.
) or you could supply crappy external master clock, but that just brings us back to well-designed vs. “high-end”.
