I’ve tried most of those optimizations and agree in general that they do affect sound quality.
This is because that’s what I hear, not because of any belief system. It’s fair to say that each optimization typically varies from “subtle” to “very subtle”, so not surprising that some people won’t notice - but it does add up.
Many audiophiles, across many different systems, also agree, but they’ve given up talking about such topics on this forum because of the negative (and often aggressive and sarcastic) responses from some members here. Such audiophiles will find alternatives to Roon where they can. I still love the Roon UI, so put up with any SQ deficiencies, and I do those optimizations to make Roon sound a bit better than its default setup.
I come from an electrical engineering and computing background, so I understand why some of these claims don’t seem to make any sense from a scientific/engineering perspective. I’m also fully aware of mind tricks such as expectation bias that can (and often do) fool any sighted listening experience.
I can’t give a direct answer to this, but I can say from personal experience that it makes a huge difference if you directly connect a Melco N100 via USB to a Lyngdorf MP-40, or if you put a Mutec MC3+USB in between which completely rebuilds the clock signal.
Maybe it also depends on the computing power of your core. I use a PrimeMini4 NUC with Core i7. When I added more RAM and changed the BIOS settings so the NUC was not throttled, the sound became better. Maybe if your NUC is very performant, those Roon settings that affect the CPU load (like the audio analysis) do no longer play a role. And then people make different experiences with the settings and start to argue who is right.
There is no (audio) clock in USB to begin with. Rather unlikely that Lyngdorf does a bad job clocking USB input, too. The price tag of Mutec will certainly make the sound seem better though.
Either it has drop-outs due to processing speed < 1.0 or it did not. People who ran blind tests never found any difference, and people who herd the difference never ran any blind tests, so there’s that…
Many parameters can affect many outcomes. Everything matters to varying degrees.
But based on my own experience across 3 different servers, plus other people’s comments on a range of different systems, I’m confident that, in general, the optimizations referenced in the OP are independent of processor power, processor loading, connection type, etc. For example, a lightly loaded i7 server outputting over AES may well sound better than a heavily loaded i3 server over USB. But both will still be impacted by these Roon optimizations.
I’m much less confident that these sometimes subtle differences can be heard by everyone.
And I’m absolutely certain that nobody’s mind will be changed by this discussion
Actually it doesn’t. Digital data transfer and calculations are just as correct with a light load as with a heavy load (if there are no bugs). If it was different, most things in the modern world would fail permanently.
We’re starting to get into an unwinnable circular debate. Bits-is-bits, blind testing and expectation bias debates never end well, so I won’t continue. I just wanted to provide some balance to the overwhelmingly one-sided posts so far on the topic of Roon optimization.
With “guides” for improving sound quality you should be very skeptical reading such at head-fi. There is sooo much voodoo talk on this site ending up in total nonsense.
Try out the different options you have in your very personal situation/environment. And stay with those you like the most
I agree that roon offers very few options to really change the final audio output besides the integrated DSP which intentionally can change the digital audio data significantly/audibly, before rendering it.
Assuming that there are no buffer underruns or overruns, any operation performed by a digital audio device (Roon server or (DACless) streamer) to “improve” audio quality are, by definition, a DSP operation. The loading on the audio server should only matter when at the point where additional loading causes the server underrun (buffer overruns should never occur).
Provided the device is working well enough to keep buffers happy, there is litterally nothing that can be done to change audio quality in the digital domain whilst preserving ‘bit-perfect’ data transmission.
Sound quality can a subjective thing - what sounds better for one person may not sound so good for another. Even when being very objective (measurements, double blind testing), often something that works well in one environment may not work well in a different environment (if this was not true there would be no need for room treatments and corrections). Even things like dynamic range compression (generally considered a bad thing when listening in quiet environments) can be advantageous in noisy environments (like your car) because it allows you to hear elements of the sound that would otherwise be lost in the environmental noise.
The best that can be hoped for the digital components of a modern audio system is that they are perfectly transparent (bit perfect), or that they differ from this ‘perfect transparency’ only when the user deliberately adds modifying operations (DSP) and these DSP operations don’t do anything beyond what they are supposed to do (like introducing artifacts). This is what Roon aims to deliver. IMHO, Roon does this very well.
There’s one potential exception. When it comes to DSD transport options. Natively/dCS/DoP in contrast to DSD2PCM. In theory, because a signal conversion from DSD to PCM would alter the signal. Whether you may hear the difference or not is a different thing and also depends on the very endpoint if this converts to PCM anyway or not.
And some may this conversion consider not to be some DSP since this is located somewhere else in roon but not in the “DSP” area.
But one thing is for sure, in roon the only really effective way to change the final output to the better or to the worse is by playing with the DSP options .
I have run roon on windows, mac and linux and they all sound different to the same endpoint. As all are bit perfect and “bits are bits”, I wonder why. And… one sounds better to me.
.