Tidal Desktop application sounds better than ROON on the same box and with the same driver, why?

“De gustibus non est disputandum”


This is not a statement you should be comfortable making.

Managing analog domain effects like “computer noise” isn’t something that is or is not taken care of–noise is continuous, not discrete. If we’re being intellectually honest, the best you can say is “I bought and installed some products that claim to mitigate computer noise” not “the computer noise is taken care of”.

The scientifically accepted methods for measuring perceived effect are generally impractical in an audiophile context (gathering a representative population, controlling for interacting factors, designing/executing/repeating a double-blind study that proves statistical significance of an effect). Some fields invest in this sort of rigor (medical testing, for example), but we are not in one of those fields. I think sometimes we lose track of that perspective when discussing this stuff.

So what we’re doing here is not stating why things are different–we are theorizing about why they might be. No-on in this discussion is prepared to do a rigorous experiment, so we shouldn’t treat our conclusions as facts. In these discussions, I often ask myself–would an expert feel comfortable making this statement with 100% certainty? And the answer is seldom “yes”.


The first thing to be sure of is–are the bits going to the DAC the same in both cases? When USB is involved, I like to verify this by sniffing the USB bus. If the bits are different, then the investigation stops there. That difference must be eliminated before proceeding to other possible explanations.

But lets assume that the bits are the same. What else could be causing a difference?

Since we’re talking about USB, it’s important to understand a few things about UAC 2.0–the protocol spoken to your USB device–is an asynchronous data transmission protocol with error detection:

  • Asynchronous means that it decouples the exact timing characteristics of the two sides of communication. Instead of requiring that data arrive “in real time”, it must only arrive “in time”. Because of this decoupling, variance in arrival time of USB packets do not cause corresponding timing differences in rendered audio samples.
  • Data transmission means that the protocol transmits information, not audio signals. That means that the rules of information theory apply to this process.
  • Error detection means that if data is damaged in transit, it will be dropped instead of being rendered with subtly degraded quality.

After transmitting data through such a system, we can be sure that if the system hasn’t failed catastrophically (dropouts or playback stopping) that the information has arrived at USB interface module within your DAC correctly, and in time for playback.

Taking a step back, if data is the same, and neither Roon nor “X” are causing the DAC to fail totally, then we can be sure that the data itself is not the channel through which qualitative differences are becoming perceptible.

So what else is there?

Since the information is provably intact and identical, and a sound quality difference is perceived, the cause for the perceived difference must be caused by something out of band of the information stream.

Here’s a theory among 20 other theories I could come up with. I’m not claiming it to be true at all, just floating something so we can pick it apart:

When TIDAL transmits audio to the TIDAL app, the data is delivered in a FLAC container. When Roon transmits audio over RAAT, it is transmitted as PCM. The PCM stream is roughly twice the bitrate of the FLAC stream, so it creates extra work for the network interface chip–but–the FLAC stream requires an extra decoding step on the CPU that is not required with RAAT.

Both the CPU and the networking hardware radiate electromagnetic interference which may influence other components in the audio system. Maybe Roon and TIDAL sound different because effect size of the increase in network traffic is larger than the effect size of the increased CPU activity in this particular computer.

For a second, assume that this proven fact–would this be proof that Roon’s approach is inferior? Should it be an argument that Roon makes a change?

What about other setups? Maybe it’s only this particular network chip, and other network chips emit EMI at a consistent level regardless of traffic. Maybe the variation is actually related to a detail of the driver not the chip. Maybe it’s only one revision of the chip. Maybe the chip isn’t at fault, but rather the arrangement of the passive components around it. Maybe it’s the driver, and the next driver version fixes the problem. Maybe some of those in your machine came from a bad batch and aren’t within tolerance, but aren’t bad enough to make the interface stop communicating. Maybe, …

In audiophile discourse, people tend to black-box components in the system at the level of our personal understanding. “computer noise” is an imprecise term–it does not belong in a rigorous discussion. “network chip” is also imprecise. I am not an electrical engineer, but I can think in great detail about how software and networked systems work inside. Those details feel bigger to me than hardware implementation details that I am not as familiar with. The difference between how large an implementation detail feels in your mind and the actual objective effect it has on sound quality can be huge.

But more to the point–that whole line of reasoning was conjecture. We live in the real world, where we must make decisions about how to build software. How sure should we have to be about that theory in order to act on it? More sure than I am about that one, surely.

TIDAL made their choice to transmit compressed FLAC because it’s cheaper and more reliable for them to do things that way. We made a choice to decode/process audio in the Core and then transmit it as PCM because our architecture accommodates lightweight endpoints that cannot do that processing themselves. TIDAL works on my phone in the car. Roon does not. Very different products, very different architectures, very different choices. More importantly–the choices were not made with the goal of increasing sound quality in a particular system in either case. The effect that those decisions have on sound quality is incidental and accidental.

There are billions of possible combinations of DAC, Amplifier, Speaker, Network Switch, Computer, Software, … And that’s just stuff you associate with audio in your mind. Your audio gear is just as connected to the power grid. It may source its energy differently at night. Your refrigerator cycles on and off with a mind of its own. Cell phone traffic from the nearest towers varies at times of day. I’m not making claims about the effect size of any of these things, just trying to bring some perspective to how complex things get once this door is opened.

No experiment conducted on an audio system installed in a home is ever well-controlled for these factors. And no manufacturer can effectively control for them either. Companies making audiophile products do not have unlimited resources. They work with their own products, and perhaps a few representative configurations for QA–not the full field of system permutations that the products might eventually be a part of.

But if these out-of-band effects matter (and many audiophiles clearly behave as if they do), then who should be responsible for them?

This is how I would look at it, assuming “different bits” has been ruled out as an explanation…

First–Each product is responsible for what happens inside of their walls, for implementing interoperability standards properly, for minimizing forms of interference that it may radiate, and for not accepting interference that it may receive. This set of rules makes the world go round. We should hold all manufacturers to this standard.

Second–if the theory is that the DAC is accepting interference from the network chip (or any other source), the party most equipped to fix this is the DAC manufacturer. Help them reproduce/measure the effect, and they can work towards a technical solution. This is where most of the accessible improvements will be in practice.

Third–since the effect isn’t in the information stream itself, I would direct skepticism at the filtering/isolation add-ons involved. Isn’t their stated purpose to mitigate out-of-band effects to the point where they become inaudible? If they are working, why is such an obviously audible effect making it through?

Fourth–if interference is traveling through the air rather than through wires, increasing space makes a difference because of the inverse square law. This is why one of the very few sound quality recommendations that we make is to put space between products that must be in the listening room and products that could be moved outside (like media servers). Physics tells us that if there are out of band effects traveling through the air as RF, increasing space will mitigate those effects by a certain amount.


I’m interested in doing whatever can practically be done to improve perceived sound quality.

We receive all kinds of sound quality feedback–positive, negative, sounds the same as. Sometimes the privately stated opinion of the manufacturer is very different than the opinions of their users (of course, no-one wants to be rude and say “we think you’re wrong”, so they rarely make those statements in public).

Very little of the feedback we receive is technically actionable, or even reproducible. Yes we try. Often.

The people in the best position to criticize our handling of audio in a technically actionable way are our hardware partners–and they rarely do. The most useful feedback is “you are doing X wrong. It affects our product in this way. Please fix”. Of course we take that kind of feedback seriously and act on it when it comes (these days, not so often…).


I agree with Gu-Gu, I love Roon and am not complaining, my Roon is on an MacMini and I have two different Dacs. For MQA I use a Merdian Explorer 2. For non MQA I use the Optical out on the MacMini to a Prism Lyra 2. I’m an audio crazy with a very resolving system. The difference in the Tidal app and Roon is very clear as Gu-Gu states. The Roon app has a great remote, the Radio lets me explore my large CD library. I also listen to a lot of Vinyl with a large record collection. My point is SQ is about something I’m sensitive. I also think the MQA on both Roon and Tidal is much better than non MQA.

I got a coupon for 2 months Roon trial when I bought my AQ Dragonfly Red and the reason I originally got annual membership (not the lifetime I switched later) was the difference I saw between Tidal Desktop App and Roon (Roon was audiophile ear better). I have to confess that I did not change any setting in Tidal Desktop app. The only difference I have with @Go_Ga is my Roon Core runs on Ubuntu Linux and my desktop that Tidal runs is Mac. As you may know Mac and Linux have better native USB drivers than windows. Schiit provides a USB driver for Windows and not Mac and Linux. I have never run Roon on windows, but Plex server (I use it for video) on Windows performs so bad compare to Linux, due to OS dispatching algorithm of Windows(mediocre at best). Movies that I have recorded digitally on windows all have distorted gaps throughout the movie . Again, I have to confess that in this case I tried both windows 7 and 10 and not the expensive 2012 server that @Go_Ga uses.

Hi @brian,

Thank you for taking time and posting such a long post. Unfortunately, your post explains nothing to me. Yes, I agree there are too many variables here however there is a number of audiophile players that consistently sound better than ROON in the same environment. I’m sorry but as the end user I don’t really care about how many different system your product is intended to run on. All I care is how it sounds in my system. I don’t want to sound like a troll but I also don’t buy your theory about “interference traveling through the air rather than through wires” (this must be a joke) and other voodoo stuff. I still like the UX of your product however.


Have you ever heard that sound that car stereos used to make when a GSM cell phone was about to ring? It became less common over time because people started filtering those frequencies out explicitly on the “receiving” side as cell phones became more popular, but that’s an example of RFI that many people are familiar with.

We have a big library of hardware here–I’ve run into more than a few DACs that pick up similar interference from normal household stuff. One that is sensitive to a displayport monitor when it’s doing heavy screen updates…another that is sensitive to WiFi transmissions nearby, and so on.

This is without direct connection–and easy to hear by playing silence through the device, turning the volume up, plugging in headphones, and creating the interference.

1 Like

LOL :joy: yes it was about 15 years ago last time. My DACs are dead silent when no signal even if a crank the volume

it’s a statement about design philosophy and the things we value during the design process. Other players specifically try to be as light as possible. We do not treat that as a primary design goal.

We do not treat treat lightweight as a priority when designing the core. Our library management is heavy. We keep large search indices in RAM. We do background processing–syncing your TIDAL library, updating metadata, audio analysis.

Some lightweight/audiophile players explicitly avoid this kind of thing, because they want to create a quiet, resource-light environment for playback.

We take another approach–provide lightweight endpoint implementations (Roon Ready, Roon Bridge) and let the core do what it needs to to produce the best UX.

1 Like

All of the hardware that partners sends us passes through my hands. You would be surprised how many modern, well-regarded DACs are not silent under these conditions. It’s definitely not the majority, but more than just a couple…

1 Like

Then why the lightweight endpoints still do not sound as good as audiophile players in the same environment? Sorry, again, I don’t mean to troll…just want my ROON to sound better

Correct me if I’m wrong. Your software consumes a lot of resources when indexing a library and performing the audio analysis. But once all that is done, retrieving the indexed data is a very lightweight operation. I’m a software developer myself and I don’t believe that retrieving a record from an indexed 1,000,000 records database can be a challenging task for modern CPUs. I don’t take into account any DSP of course.

Hi @brian

That is a very informative post.

You will know that I’m an avid supporter of Roon across these forums - and you may not know I’m also a big supporter elsewhere too.

But just for the purposes of completeness, your post considers everything other than Roon and RAAT itself.

That’s not to say that there is an issue or compromise with RAAT that affects sound quality and at the same time if you knew of a downside of RAAT that affected sound quality I wouldn’t expect you to shoot yourself in the foot and tell the world - instead, I’m sure you are working at it.

But there are enough people (end customers) out there that have commented on Roon’s sound quality that I hope you continue to listen and continue to try and find what it may be, if it is indeed RAAT.

Again, much love but as someone who has purchased 2 lifetime subscriptions (one for myself and one I purchased for my old man, my dad) I hope you understand that sound quality is numero uno to me.

To be honest if I never tried Audirvana recently I’d be non the wiser and just as happy as my old man is. But unfortunately I did after I read the opening paragraph in John Darko’s post here:

Anyway I hope I haven’t offended. I have tremendous respect for all you guys at Roon.

Keep up the great work and please continue to have sound quality at the top of your priorities.

1 Like

That long post was trying to explain that there is not an easy, direct answer. Roon and TIDAL do many things differently. Assuming the bits are the same, and you are sure you perceive a difference, then you must believe that the effect is happening out of band of the information stream.

Those out of band effects involve more components than just Roon, but the phrasing of your question is treating Roon like a black box, as if swapping the software is a single, isolated, well controlled variable that does not have ancillary effects–which is not the case.

This, in my mind, is the real voodoo–we’re starting with a perceived (but not scientifically established) difference, assuming the bits are the same, and thus opening the door to explanations that are very indirect and complex.

Personally, I am extremely skeptical of my own listening perceptions because to my brain that is where the most dramatic variation is most likely to be. I do not have the level of certainty that you seem to have about personal listening test results, ever.

I’d still like to find out if the bits are the same. I recall TIDAL doing something with volume leveling, and that album you mentioned is poorly mastered (lots of inter-sample overs). If TIDAL is dropping the volume–even by a tiny bit–that could explain a difference.

Roon is an in-RAM object database. Big load at startup, huge footprint while it’s live. Garbage collector walking through it now and again. Not very analogous to a traditional DBMS. The object count is roughly 10x that of other music players for the same set of content because of all of the extended metadata, too.


Actually, any album sounds better from Tidal desktop. I spent most of the weekend listenning and comparing using different albums and settings. I want my ROON to sound as good as Tidal at least and as good as MinimServer>>JPlayStreamer at most.

USB Regen is not doing USB galvanic isolation. The replacement product ISO Regen does (make sure the ISO switch is set to 1, not ON).

It didn’t consider Roon because we’d already removed Roon from the room. It did consider RAAT (see the whole subject about data rates, PCM vs FLAC, etc).

We’re not averse to acknowledging our faults. This kind of case is a little bit tricky because all we have to go on is a loose collection of opinions, many of which are based on old versions of Roon or RAAT (anything <1.1.21 is out of date for SQ evaluation), and many of which contradict each other.

More than one time, manufacturers have come to us saying “our users say RAAT doesn’t sound as good as UPnP, but we cannot prove a difference in our listening tests”. I’ll leave unsaid what the most logical explanation for that is…

If you truly want to see progress on this, help us find repeatable examples sound quality problems that we can see and work on in-house. We will work on anything that we can reproduce conclusively.

The reason I mentioned hardware manufacturers above is this: if a manufacturer feels that RAAT is having adverse effects on their product’s sound, I’d expect them to come to us with a clear report detailing what we are doing to make their hardware not sound as good as it could so that we could address it.

If there’s a problem and no such report, we can only assume that either the manufacturer does not feel there is a difference, does not care enough to investigate/pursue the difference, or they do not understand their product well enough to make a coherent report.

Roon Ready partners receive the full source code to RAAT, and can customize it as they see fit to get the sound quality they need. Some totally re-write the “output plugin”–which handles the communication with their audio hardware. Some just do smaller tuning. Ultimately the responsibility for ensuring the sound quality of their product is with them. This idea is core to our certification: we are responsible for the user experience, our partners are responsible for the sound quality.

I would not–as you sometimes seem to–expect Roon to take ownership of the proprietary details of another manufacturer’s product and address their sound quality problems indirectly via a generalized change to RAAT or Roon.

We make generalized improvements all the time–usually by reducing resource usage–and these benefit everyone.

What we don’t do is make our whole public message about sound quality–because we have so much other stuff to talk about.

This may create the perception that we care about sound quality less than others–which is definitely not the case.


Fully understood Brian.

If you have a Macbook with A+ , a Chord Hugo2 and Sennheiser HD800S cans I would love for you to see/hear if you can notice the difference that I can.

Even with RoonServer in a different room, only RoonBridge running on the Mac and both the Hugo2 and Macbook both running on batteries…

Or if you’re ever in Australia (Melbourne or Sydney) please let me know and you can do a blind test on me and listen for yourself - if you’ve never heard the observed and reported differences yourself.

1 Like

I also feel that Roon offers worse sound quality than other software solutions but I fully understand that this is hard to quantify and therefor work on. But what is much easier is to consider the “drop-outs” on DSD you get with a Chord Dac, this is clearly easier to quantify. Maybe this “irregularity” in how Roon delivers data to the DAC can also be a reason to the worse sound-quality? Even if not, just fixing the drop outs would be good, no?

Also putting the sound quality issue on all DAC manufacturers is a bit strange, especially as many have old DACs that cannot be fixed, rather users would need to buy new DACs?

Dropouts on Chord DACs are not exclusive to Roon. This was one of the first thing we determined when investigating the problem. I have reproduced them with Roon, A+, HQPlayer, NAA, …

I think holding Roon responsible for out of band interactions between a computer and a DAC is a little bit strange, being that we don’t directly control what your computer puts into the environment nor what the DAC accepts from it. What we do control is whether the audio stream is delivered intact and on time. That is obviously our responsibility.

The later comments about hardware were in context of the Roon Ready program–where the responsibility lines for sound quality vs ux are clearly drawn, and there is an active collaboration.


Thanks, yes that I agree with.

Did you get any response from Chord then? Are they working on it or do we (i.e. the end-users) need to bug Chord about this.