NVMe for music content

2 posts were split to a new topic: How do you make an already owned DAC into a network-connected DAC

@danny I too would really like to see that blog. Please please ā€¦ are we there yet ā€¦ are we there yet :joy::joy:

Would you say just how interrupts and swapping are causing ā€œnoiseā€? And what is ā€œnoiseā€ here?

If thereā€™s no paging-out/swapping/paging-in, then a CPU will simply stall (be doing nothing else) until the backing store yields up its contents to fill a physical frame. Useful work will in general go WAY down. And even then, itā€™s not completely obvious (to me anhyway) that the CPU will end up performing its current work that much faster than might have been true if/when a more common paging-out/swapping/paging-in mechanism had been used.

And, by the way, modern OSes have gotten pretty smart about recognizing patterns of CPU and I/O use and minimizing ā€œunnecessaryā€ paging activity.

I agree that one could write an very special purpose OS that would favor Roon (or something) at all costs. But that sort of thing is more commonly reserved for real-time requirement like controlling missiles, nuclear reactors and maybe medical devices. Such an OS will have a different business case, I suspect, from the one Roon follows.

ROCK, based on whatever OS, would see benefit if itā€™s difficult for anything else than Roon to be run on it, simply because thereā€™ll be less competition for CPUs, less I/Os and so forth. In other words, reducing use can work toward some of the benefits that a real-time OS achieves, without the cost of writing/maintaining that special-purpose OS. In other words, a focused, application-preventing OS like a tailored Linux (where one can tweak source code) might be the trick.

In short, I donā€™t necessarily disagree with your points, but I think other things deserve emphasis.

Good questionā€¦

My Definition of Noise
I would define ā€œnoiseā€ as ā€œperturbations of power whose presence contribute a range of audible and perceived effects upon the enjoyment of music reproduced by connected music playback systems.ā€ This noise is most often injected into and communicated from component to component by the ground plane, but it could have higher-level manifestations such as intermittent signal degradation on isochronous data transmissions that lack error-correction or retry mechanisms in their protocols (such as USB Audio).

SSDs and spinning disks are notoriously ā€œnoisyā€ (whether itā€™s transistor chatter or motor noise or cell fill/drain cycles or what have you, merely operating them creates some amount of noise as a byproduct) so much so that there are aftermarket ā€œSATA Power Filtersā€ you can buy from a number of manufacturers.

CPU and OS Behaviors
As for CPUsā€¦ a CPU wonā€™t stall if it has work to do. It may park unused cores, and the kernel can and will suspend threads on every process, but the OS almost always has something going on, especially in preemptive multitasking environments (Windows, Linux, MacOS, etc.).

With enough RAM and smart cache management, the system wonā€™t need to page memory out nearly as oftenā€¦ but in a local music playback sense, it will have to retrieve an entire song or set of songs from disk on a regular basis and store them in (ideally) physical memory before shipping the bits out to the network/usb interface. You canā€™t get around that tax unless you have enough RAM to load your entire library into RAM. =^) (Iā€™m not arguing that RAM is devoid of noise ramifications either. All those cells draining and re-charging to check their state for every read on the rising/falling edge of the DRAM clock has the potential to create noise as wellā€¦)

Otherwise, the kernel scheduler will still actively context-switch one or more cores of the CPU across all active foreground and background processes, drivers, brokers, etc., giving them their little time slice in which to do work, and thereby giving the appearance to the user that all the programs are running ā€œsimultaneouslyā€. With the advent of multi-core CPUs and hyper-threading, some processes (especially intensive ones) genuinely are running simultaneously, but many are still swapped in and out of the CPUā€™s context as demands on the system vary. There are ways to give hints to the kernel scheduler that can minimize such context switches, but itā€™s all but impossible (afaik) to reliably prevent it. Itā€™s just the nature of the beast.

In any case, all this movement of memory and swapping of process contexts, changing of transistor and capacitor states has the potential to dump EM noise into the power that every connected device is drinking from (at the very least the ground plane), as well as to radiate its noise directly (either as heat or other EM radiation).

Personal Anecdote
I once had a Media PC with an Intel CPU with integrated graphics. It would dump the most heinous whining and squealing sound onto the ground plane of my system whenever I did things that changed the the video frame buffer (e.g., moved a window, scrolled in the browser, played a youtube videoā€¦ pretty much anything that changed a significant amount of pixels at once time. Even moving the mouse could sometimes be heard!)ā€¦ it also would make this low-intensity scratching sound whenever the SSD was accessed (either to load a song, launch a program, or even to boot the OSā€¦ that was a veritable symphony of low-intensity noise). Other than these issues, my system was dead-quietā€¦ which made the noise all the more apparent. I was using a USB-powered DAC and my operative theory was that noise was being dumped by the PC onto the power system, probably the ground, which was then being conducted to the USB DAC. The power/ground variances got incorporated into the final output signal after the D/A conversion and amplified to line-level during the output stage (and again by my pre-amplifier and amplifiers) and thus became quite audible (and annoying!).

Iā€™m still using the same DAC, but iā€™ve insulated it from my PC via a Fiber Media Converter (FMC) and a Sonore microRendu (powered by a linear, regulated power supply). This has dropped the noise floor below the level of my perception and commensurately increased my enjoyment of the musicā€¦ especially the quieter parts. :slight_smile:

Bottom line (for me) is that computers are electrically noisy things. Whatever I can do to minimize the noise they introduce into my music is a worthwhile pursuit. Despite all this vilification of all things noisy, I still enjoy vinyl immensely (even though dirty and badly pressed slabs are a haven for noise). Go figure. =^)

Your anecdotal case is pretty common, Iā€™ve even heard the similar thing while activating the GPU on a battery operated laptop that had nothing to do with the sound being played in the room, not even on WiFi or connected via Ethernet. RFI is the only explanation since it was totally isolated electrically.

But where do they inject the noise? An SPDIF or analog out on the machine? Sure. A USB DAC connected to the machine? Possibly. A properly isolated (EMI, RFI, audibly) network DAC elsewhere? No way. The noisiest computer with the worst power supply can not mess up the audio if being played to that DAC via a sensible audio transmission protocol. Itā€™s one of the main reasons the Roon Team always recommends networked DACs over USB.

As long as thereā€™s proper galvanic isolation between the source and the sink and the bits arrive correctly via the sensible protocol, youā€™re right about the PC no longer mattering. Iā€™ve pretty much proved that with my own setupā€¦ so long as the network wiring in question isnā€™t acting like an antenna and receiving noise from the surrounding environment (RFI/EMI?).

Iā€™m speculating some on the latter point, seeking to explain a repeatable phenomena Iā€™ve experienced with multiple witnesses: Iā€™ve heard fairly dramatic differences between differently constructed Ethernet cables from various vendors (e.g., Nordost, Audioquest, and Wireworld make cables to similar specs (Nordost and AQ with various makes of Cat 7, Wireworld with 3 different flavors of Cat 8, all of which resulted in a different quality and character of sound from a Roon-driven microRendu using identical source files and/or TIDAL tracksā€¦ both at my house and at a friends on very different systems miles apart)).