The great Sean Adams, architect of the Slim Devices/Logitech Media Server, Squeezelite, the visionary who created the first integrated software and hardware ecosystem for ripped music playback, wrote:
You claim that an:
audible
measurable
hypothetical
improvement in sound quality can be attained by:
upsampling
increasing word size
vibration dampening
bi-wiring
replacing the external power supply
using a different lossless format
decompressing on the server
removing bits of metal from skull
using ethernet instead of wireless
inverting phase
installing bigger connectors
installing Black Gate caps
installing ByBee filters
installing hospital-grade AC jacks
defragmenting the hard disk
running older firmware
Your idea will not work. Specifically, it fails to account for:
the placebo effect
your ears honestly arenāt that good
your idea has already been thoroughly disproved
modern DACs upsample anyway
those products are pure snake oil
lossless formats, by definition, are lossless
those measurements are bogus
sound travels much slower than you think
electric signals travel much faster than you think
thatās not how binary arithmetic works
thatās not how TCP/IP works
the Nyquist theorem
the canāt polish a turd theorem
bits are bits
Your subsequent arguments will probably appeal in desperation to such esoterica as:
jitter
EMI
thermal noise
existentialism
cosmic rays
And you will then change the subject to:
theories are not the same as facts
measurements donāt tell everything
not everyone is subject to the placebo effect
blind testing is dumb
you canāt prove what I canāt hear
science isnāt everything
Rather than engage in this tired discussion, I suggest exploring the following factors which are more likely to improve sound quality in your situation:
Was this aimed at me? ASR do tests with test tones and measuring equipment. The human part is just to operate the equipment and document the results.
Now granted, then your next problem may well be:
āIn science, contrary evidence causes one to question a theory. In religion, contrary evidence causes one to question the evidence.ā~ Floyd Toole .
The legendary Sean Adams. Yep, instead of worrying about pico volts of noise on a digital signal, buy some room treatments, or upgrade your speakers - either of which will have a much bigger impact.
So Iām now one of the crazy ones. I got my WiFi connection to be stable and think using WiFi instead Ethernet actually made a noticeable improvement with my streamer. But I still think RAAT is best end point. And differences between RAAT and Squeezelite much more subtle than effect WiFi has.
As far as using WiFi vs Ethernet think improvement would be any electrical noises not being passed thru. I donāt think has anything to do with bits are bits but electrical noise effecting eventual analog output. As far as software having an effect, think it just has to do with how efficient it is and how that effects the end point performance. Internal noise can be passed along.
Let me point out I donāt like being one of the crazy ones. And Iāll still go back to all this is so minor I canāt see spending money on Ethernet filters, switches, or moving away from roon to other software. You have to balance out money and convenience over so called ultimate sound quality.
Lots of talk about Ā«some customers sayĀ», different file formats, RF noise etc. All things that are something Roon software canāt solve. Well, if you computer introduces noise, do as Roon suggest: Separate the core and the endpoint.
I maybe repeating myself: Roon offer a perfect transport of audio data between the source and the endpoint. This has been tested by Amir/ASR, me and many others. Itās an easy test.
You canāt ask for more āSQā. From the endpoint, to the DAC and all the way to you ears, youāre on your own. Sorry, you are outside of Roonās software domain.
All unwanted timing should be killed in buffers between, and including, the endpoint and the DAC. If not, get new equipment. Cheap equipment can do this.
RF noise is a thing. If your streamer or USB cable feeds your DAC with unwanted audible noise, change something. But it is not in the domain of Roon software.
The whole premise of this thread is wrong. There is no āsound qualityā in Roon. There is only data.
I think only real issue I see is someone is comparing Audivana vs roon core hooked up directly to a dac. Audivana is designed as a stand alone and even has further enhancements to make your computer more efficient. Roon core is processor heavy and meant to sound best splitting core and end points. I personally think their RAAT end point works great and doesnāt need any changes. Anyone expecting the core to sound better with future upgrades should probably look elsewhere. Luckily when split, the core has no effect on the end point.
This from 2009 and has become much more well understood and accepted since then. Thatās why it surprises me that some still making this argument. I have limited time to reply so I just plucked this from my search results, but it should point anyone genuinely interested in the right direction.
Iām familiar with jitter, but Iām not sure how itās relevant to this discussion. If Roon sends bit perfect data to the DAC any jitter in the system is, by definition, introduced after that point.
Thatās why I initially punted on addressing the photo remark. Those who raise that question tend to not be interested in hearing the answer.
You made it relevant to the discussion by asking me to provide you the information I actually took the time to search out and provide provide - and then you accuse me of bringing up something not relevant to the discussion. Thank you for that. I thought I had seen it all but that was a first.
Jitter, what I called unwanted timing, is killed in a buffer. Asynchronous data transfer, like TCP and Ethernet, works like a buffer by itself (the packets/frames). RAAT use TCP. So RAAT delivers jitter-free data to the endpoint. From there, jitter can be introduced.
Using an asynchronous USB with a buffered DAC with its own clock, jitter is no problem. The DAC clock is the king. A DAC that relies on an external clock is more on the thin ice, or especially when both internal DAC clock and external/signal clock is both in play. Synchronous data streams, like S/PDIF over coax or TOSLINK, are more prone to jitter. Good source clocks and standards exist.
But again, this is outside the domain of Roon software.
Everyone talks about noise entering the DAC from a USB or ethernet connection. Signal to noise ratio is measurable and most reputable DAC manufacturers will report this value. My Khadis Tone Board reports a snr of more than 120 db. That is significantly beyond audible levels. Electrical noise is not a factor in a well designed DAC and unless something is seriously wrong, noise cannot affect the incoming signal and be passed on from the DAC.
Translation: Only people with very expensive equipment, including $1000 Ethernet cables, clock regenerators, linear power supplies, and off-the-shelf computer parts in $15,000 aluminium enclosures know what the ātrueā sound is.
My apologies if my comment offended you, but what I actually said was that I was unsure as to its relevance, not that it is irrelevant. My uncertainty arises from much the same point that @rockphotog raised in his comment (posted just after mine) that RAAT delivers jitter-free data to an endpoint because the data stream is asynchronous. As such any jitter in the system must come from elsewhere.
There are multiple clocks involved. If I write a piece of software that causes computer activity - there will be power surges within the computer to respond to that. This can dump noise onto the ground plane and itās my understanding this noise can degrade the performance of the clocks.
Iām only giving a short answer here just to point out that software can trigger computer activity that can generate noise. The solutions that are reported to sound better than Roon take this into account and attempt to minimize activity. Itās my understanding that Taiko is even taking this t the extreme for their Extreme by turning off the network card when itās not needed.
Thank you for your kind response and my apologies for over-reacting. Iām not so sure that ādeliveringā is just as simple as a one-time handing off the data. Do they implement any kind of flow control to let the server know that they are ready to accept more data? Is it then FIFO (first in / first out) from their endpoint?
I have to admit that Iām biased to think that itās not so simple as some like to think. I work in technology so I have come to recognize the we mostly deal with onions where peeling back on layer only leads us to finding another layer.