The trouble is that the flowery audiophile jargon is the entire point of the industry. Before any kind of architect, be it in the fields of construction or sound engineering, can produce something that touches the sublime and makes his or her audience reach for words that try to describe the otherwise intangible, they have to get an awful lot of maths and mechanics right and any tiny or cumulative errors there, whilst very hard to detect or quantify later, might well have a profound effect on the aesthetic success of the outcomeā¦
That was with the older Wolfson dac chips this new generation uses different chips from ESS and donāt do it and itās not mentioned at all where they use to.
Hello,
When I had my evo 150, I also found the sound better if I listened directly from Qobuz, more accurate.
Now that I have a Linn Selekt DSM, the sound is rounder, warmer, more tasty with Roon. If I listen directly from Qobuz, the sound is drier.
I now much prefer the sound of Roon.
I speak French; I hope the translator has rendered my impressions correctly.
8 Likes
Thank you - itās good to hear that someone else has the same experience. And to know that itās not necessarily either ROON or the EVO at fault but that sometimes there can be a ghost that only manifests when two particular machines come together.
2 Likes
Ho Boris,
Excellent writing which, shows your profound knowlege. If I am to add, it is, not bit-perfect when the bits are converted to PCM and handed over to a device to deliver those pulses to the DAC. PCM not bit perfect once sent.
Measure work by subtracting the source and the destination/output of the DAC, which leaves some noise. That noise could be some harmonics essential in the sound.
1 Like
Thanks for the info on the MU1. It answers two questions I have continued to have:
Why donāt I hear anything but great sound from Roon?
Am I imagining the great sound or did Grimm Audio design out some of the problems other folks hear?
Regarding the original question asked by the OP ā long ago when using another streamer, the difference between wifi and wired copper ethernet was clear.
I appreciate your pragmatic approach. It is easy to get frustrated with audio, but the whole point is enjoying music.
3 Likes
Itās not that sound quality differences have anything to do with Bit Perfect. All the users that swear, āRepeat after me: Ethernet by its own nature absolutely has to be Bit Perfect.āare of course correct. Iāve no argument against this statement at all. Of course the internet would collapse with out keeping the ones and zeros straight.
But for audio my guess is that ā jitterā can travel along the Ethernet or WiFi highway that donāt affect the ones and zeros.
Iād guess the number one offender might be extra CPU stress. The more complex the software and the more actions the CPU has to focus on the more stress occurs. Iād guess this is be f the reasons the playback software all on this site might use continues to update its specifications for faster CPUās.
Thatās one reason my PC only does one task: send my stream to the endpoint. Iāve tried adding tasks for this PC to accomplish besides streaming my files. Each time Iāve added upsampling to the load, downloading new music files, ripping CDs, etc. I use a separate device as an endpoint and a separate device for upsampling. Iāve noticed that other streaming programs that use far less resources than ROON, often sound somewhat better. My hypotheses less stress on the CPU.
Providing extra tasks for the CPU to perform has always resulted in hits to sound quality. For instance I use WSY2K18 and the AudiophileOptimizer because.it produces less pressure on the CPU. You can try AudiophileOptimizer yourself. There is a fee trial version that works with the latest versions of Windows. Check it out by dual booting. Iām certain you will hear a difference in the way ROON sounds using Windows with AudiophileOptimizer or without.
Another experiment might be to use ROON and HQPlayer together. This combo is supported by ROON and HQPlayer. To me I hear mixed results if both programs are run on the same PC. As one uses the various options on HQPlayer (there are thousands of permutations) one can literally shut down the CPU to a crawl and it might even overheat.
If you use a separate PC for ROON and a separate PC for HQPlayer that problem is resolved and the results can be stunning.
There are many reviews both formal and informal that support these findings.
And of course all of these options do not compromise the truth of āBit Perfectā. That is, as perfect as invention by man can be perfect.
2 Likes
The ones and zeros must be stored into a buffer before being processed; they cannot be consumed directly off the wire or the air by the DAC or the software. Once the bits are stored neatly in the buffer, all the jitter along the transmission becomes immediately irrelevant.
3 Likes
Thanks, but how exactly does it become not bit-perfect? Where is the data being changed? Itās not like PCM (or anything else in the computer) were anything but bits to begin with.
Jitter might have been an issue some 20 years ago when DACs were fed with S/PDIF cables and used the source clock for timing. It is not an issue with any well-designed modern DAC.
Or just run an OS that doesnt come with all the windows baggage plenty to choose out there for nothing.
You still donāt seem to understand the original question. It is about streamer/DACs, which have an internal (typically I2S) connection between the streamer component and the DAC component. Its I2S output requires flawless realtime processing. The streamer component runs different code paths for different digital sources, and those code paths are likely developed by different engineers at different times, with different testing resources. A slight difference in realtime behavior may be enough for a difference in timing on the I2S bus with (also slight) audible consequences.
Iād be actually surprised if those issues were not common given the very limited resources of most streamer/DAC developers compared with other businesses competing for the same software development talent.
(Just an extreme example: Some years ago, the reference driver for a well-known USB receiver chip had a very bad bug that would cause Roon>DAC connection to freeze on rate changes; that bug manifested itself in multiple supposedly high-quality DACs, as one can verify searching this forumās archive, showing that those DAC firmware developers were not carefully reading and testing the code they were importing.)
1 Like
Yes, I understand that. There well might be some timing differences in how different source processing might push bits to the DAC, over I2S, or two cans on a string, with slightly different timing.
I am saying that it should not matter because modern DACs do not care about I2S timing, thereās asynchronous processing and reclocking inside the DAC. Unless you specifically turn it off, how would those timing differences have any effect?
1 Like
Hereās the datasheet for the DAC chip inside the Evo 150. You claim perfect timing isolation for the ASRC/DPLL circuit in the middle of the block diagram, but those circuits are not magical and can introduce their own artifacts. Iām especially skeptical of interpolation artifacts in ASRC.
Iāll step off this train now, other stuff needs my attention.
I wish was true but some is still carried. Thatās why there are many expensive clocks and anti jitter devises that clear it out before going to the DAC.
In fact many DACs come with these devices built in.
For instance all the new PS Audio DACs come with a Digital Lens to do the job with a buffering system before fed up the DAC chips.
Of course none of this noise matters a hoot to Ethernet or Wireless transmission because the bits remain perfect.
The problem is this noise or jitter affects our sensitive DACs. But not the ones and zeros.
The Wadax digital playback system, Meridian, PS Audio, dcs and many other systems go to great lengths to filter out the noise, jitter, what ever you want to call it that rides along with the streams.
The stream almost always remains Bit Perfect. Iād guess with some extreme circumstance like an earthquake, sun spots, nuclear strike etc could cause contamination to the ones and zeros but Iād be surprised if the whole system didnāt collapse during an event like that.
The ānoiseā travels with the stream and can cause the DAC chip grief. Iād guess the better the DAC chip and surrounding electronics the more the noise is filtered out.
Iām not an engineer of any sort but Iāve worked with a variety of DACs, streamers, streamer/DACs, clocks, anti jitter devices, operating systems, and software.
Network transport is asynchronous. Thereās nothing expensive clocks can do to improve network transmission because there nothing to improve. The exact time at which various samples make it at the destination can vary greatly, so much so that it canāt be called jitter anymore. Buffers are the places were these variations are leveled, and the amount of leveling is largely dependent in the buffer size. Once these variations are handled, thereās only one clock that really matters: the D/A conversion clock.
3 Likes
Here is how one manufacturer of an ethernet noise reducer explains the benefit of their switch:
āThis is the underlying mechanism for threshold jitter: Noise on the ground-plane of the DAC causes effective jitter in the DAC chip, which modulates the audio signal coming out of the DAC. Note that the actual clock signal does not change at all. It is how the clock circuit inside the DAC chip sees the clock signal that matters.ā
For the full white paper:
If I sold snake oil, Iād have to come up with an explanation of how snake oil is beneficial.
Anyway, jitter caused by noise in the ground plane - assuming the DAC has insuficient AC filtering on the ground plane - has nothing to do with network jitter or the switchās clock.
2 Likes
Good luck, hopefully nothing too serious.
Iām not saying that reclockers in DACs are perfect just thaty after they are done, whatever timing artifacts you have are due to them, and internal workings of the DAC, not any timing differences before data was reclocked.