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.
The skinny from the @danny -
https://community.roonlabs.com/t/roon-nucleus-experience/43776/33?u=slim_fishguttz
Thanks, I give the linear power supply a try!
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.
Clock speed is dependent on work being done, i.e. calculations, irregardless of the number of threads/processes present. How do you feel about upsampling?
Really noisy when SSD or M.2 is accessed or video signal is generated.
Most of which are not active at any one time, A cursory look at Task Manager would confirm that.
Not for any well engineered DAC manufactured in the last 10 years.
Again, the Roon folks have never claimed improved SQ for either ROCK (reduced process count or not) or Nucleus. In fact ,they go out of their way to address that false notion.
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…
Please don’t.
If you want to move from MacBook WiFi to a dedicated Roon Core on LAN, simply connect it to your router/switch.
For hardware to run ROCK, consider something like this:
As for sound quality, I’ve read a report of improved SQ by switching Roon Core from MacBook WiFi to a wired setup using different hardware, for another brand of expensive DAC connected via network.
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.
https://www.head-fi.org/threads/chord-electronics-dave.766517/page-415#post-13098194
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.
Did you think it made a difference Peter ?
Latency will have zero impact on jitter in a pure digital transport.
Using networking protocols with render-side-clocking means jitter is a non-existent thing relegated to the past.
Agreed. In the Rob Watts post I shared above, I can bet the house that he’s definitely not talking (or even thinking) about jitter there.
He explicitly mentioned RF interference potentially being a factor for why ASIO sounded different to WASAPI to his ears.
That’s a public post that I can share but I’ve had private discussions with a few others of the world’s most respected DAC designers (kept private out of respect of course) and the gist is the same.
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.
Both are bit perfect but they have different latencies which contributes to the different SQ.
Agreed, which is why RF interference can potentially be much more important to discuss (according to the better DAC designers anyway)…
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.
Absurd, superstitious behavior - even for a dealer.
Monkey see, monkey do.
Hehe I’m not sure if you’re aware of the challenges involved but this is much easier said than done.
I could say certain things should have been properly “fixed” with Roon a long time ago 
but I appreciate and understand that some things are very technically challenging and take time.
Obviously things always improve with time.
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.