Sorry, I don’t understand the engineering behind this statement. The value of having fewer threads is that the Roon processes get a bigger time slice. I don’t think it has anything to do with electrical noise.
I don’t think any claim has been made for improved SQ due to ROCk. At least, there is no claim for improved SQ with a Nucleus/ROCK combination.
Having few threads means the resources for the CPU is always kept low; this results in lower clock speed, thus less current is drawn. Keeping the current low resulted in overall low electrical noise. These noise can be easily seen as ‘spike’ under high CPU clock speed. A typical PC/MAC has several hundred to thousand of threads running on the background.
Since the source of electrical noise such as ground bounce can travels to DAC, this noise can adversely affect DAC performance.
Yes, I do, I hear an improvement in SQ, mostly in the highs; better separation of instruments and clarity. That’s why I switched from PC to ROCK. I also have a dedicated Auralic Aries Mini used as streaming transport and Roon endpoint.
Here’s is a good example why people decide to go from PC to dedicate streamers…
This is a little bit different but MAY be related.
Here is a well respected DAC designer (Rob Watts of Chord) talking about how using an ASIO driver may sound different to equally bit perfect WASAPI driver… both capapble of bit perfect playback obviously.
As danny said in another thread recently, let’s not waste any time talking about bits being affected. If something is affecting bit perfect playback in your chain, you will most definitely know by audible dropouts, pops, ticks etc etc.
I don’t know if danny has discussed this with the qualified engineers at Meridian before and if they had thoughts but I wonder if it relates to similar reasons for some people (me too) observing Roon Server running on a Mac/Windows PC sounding different with RoonOS with some DACs…
Not so much just low overall CPU loading, but perhaps reducing processes that aren’t required for audio playback. Don’t ask me how it affects the analogue output or for measurements - this is just a fun discussion about potential technical mechanisms.
A qualified and respected DAC designer like Rob has the unique position of understanding both the digital side and what can potentially affect the analogue performance side…
It might be beyond the ‘bits are bits’ software/networking guys too - but maybe @danny has discussed it with the qualified hardware guys at Meridian?
This is even just looking at the example of ASIO vs WASAPI (in exclusive mode) potentially sounding different on the same hardware and same OS and same system of hardware… let alone different hardware and different OS… even while everything is playing bit-perfectly up to the DAC input…
Interestingly, 3 days ago I witnessed a dealer manually setting process affinity of the Roon processes in his US$16000 Roon Core from a Roon partner (truly impressive PC hardware by the way), in order to achieve the best SQ for his demo (of another DAC more expensive than any of our products) to a customer.
Despite it is bit perfect, the two main problems about digital audio are noise and latency. The first is obviously a big impact on SQ, most DACs are extremely sensitive to incoming noise from the source. Some goes to an extent to use galvanic isolation on its inputs.
High latency contributes to increased jitter, therefore having fewer ‘layers’ or ‘stages’ do helps to reduce this effects.
Yes it does, take for instance a WASAPI vs ASIO vs Kernel streaming protocols all have different impact on sound quality. One can adjust from the lowest latency of 64 all the way up to 4096 or even more, in the case JRiver offers up to insane 8192. The higher latency (more buffering) means the clock generates is ‘longer’ and stay in the buffer for longer time. The longer it stays the higher the jitter.
Therefore there’s a balance between how much latency vs buffering to prevent drop-outs. Of course, re-clocking using asynchronous technique (at the DAC side) will essentially eliminate jitter. As I say, on the system level, jitter is still present but this can be taken care at the DAC side.
Yes, I agree such network protocol like LAN connection is asynchronous transmission so jitter is non existent but what about PC is connected to a DAC via USB? My argument is still jitter produced by the transport, but of course the DAC can take care of this by ‘re-clocking’ internally.
No it doesn’t. You just left the purely digital domain if your clock matters on how you interpret the bits. Jitter is only “present” if the bits are interpreted badly – it’s the definition of jitter!
This is one of the reasons we prefer networked endpoints. Less legacy (USB) ways to screw things up.
This is just talking about things that don’t matter at all. Jitter is the incorrect interpretation of digital data. If the transport doesn’t interpret but just moves data, there is no jitter. Let’s not confuse the matter with items that don’t impact anything. A DAC that cant reclock the signal is to be avoided. @dabassgoesboomboom – the Meridian guys all feel that way as well.
This should be fixed by properly shielding the analog parts of the DAC and post-DAC process. Cutting the RFI is impractical and the world is moving towards more and more RFI everywhere. Those who do not, will fall into obscurity.
No A/B comparison for process affinity setting was done when I was there. According to the dealer, it was done to optimize the SQ between a Roon setup with HQPlayer and without HQPlayer. He certainly believes it makes a difference.
I see solutions out there. They are easier done than you think. Even the link you posted about about the Dave demonstrates it doable. Hell, I see so many devices out there without even a simple Faraday cage built in.