When I use the Roon app and tell it to play a song what is the process at software and hardware levels that takes place. For instance do the bits from the NAS flow to my Cisco switch and then directly to the Roon output device (in my case a microRendu)? Or does it get returned to the Roon Core running on my MacMini and then get “processed” if necessary and then sent along on its merry way to the output device? The visual I see using the app is likely not a great indicator of just how the bits move. And I’m guessing that much also depends on how the Core “system” (MacMini) is wired.
In the case of using two ethernet outputs from the MacMini via Virtual Bridge mode, I can send the output from the MacMini Ethernet port directly to the Output device (microRendu) and use the other Ethernet (Thunderbolt/Ethernet dongle) out to the switch. In this latter instance I know that the bits must move from from NAS to the switch and then to the MacMini that then moves the bits to the microRendu.
I suspect all of this is directed by RAAT and just how it fits into the software stack relative to the macOS. My knowledge of the 7 layer ISO stack is sketchy at best.
Hope I’ve not confused anyone. Just trying to figure out the best way to optimize my environment and place the best Ethernet cables in the right location for moving the music along.
The Core decodes the files and applies DSP. The endpoints do very little work, as they are designed to be very low-noise.
Put all the processing power in the Core.
Make sure you have ethernet between the Core and the NAS, and ideally to your endpoints too. If you can’t then fast reliable WiFi, with ethernet in your most critical listening locations or places where you listen to high resolution content.
Thanks I’ve got the NAS, MacMini, microRendu and WiFi access point all colocated so all go Ethernet to the Cisco smart switch. Only question is the impact on the quality of the Ethernet cable and most critical one or ones relative to keeping out any noise or electrical grounding. But that’s a hardware issue, rather than TCP/IP bit delivery.
cat5e or cat6 is sufficiently shielded to avoid an unacceptably high number of data transmission errors.
Anything else is is about EMI/RFI – and that needs galvanic isolation and a faraday cage.
There are a decent number of galvanic isolators for USB, and your DAC may already have one in it. After that, keep the RFI and the acoustic noise from the hardware far away, then the ethernet cable you use shouldn’t matter beyond the cate5e/cat6.
The dCS Network Gateway unit I’ll be getting shortly to replace the microRendu/Berkeley Alpha USB D-D converter will have Ethernet in from the switch and AES/EBU out to the DAC. I’ve been told that I should watch out for possible issues with grounding that may arise with Ethernet cables where, as I recall, the ends are using grounded jackets or such. Not clear what to actually look for. May give the Transparent Ethernet cable a go to see how well it performs between the dCS and switch. I’d thought that Ethernet is inherently safe as the endpoints are galvanically isolated. And I’m using non-PoE ports, to be safe. Would certainly like to know more about any existing Faraday cage implementations.
your dCS’s case should be a cage enough… and I would think that ground loops shouldnt be an issue inside the dCS… but some swear by fancy cables… up to you. Check what sounds better
good stuff… try to get some help and do a repeated blind test – if you hear something, by all means keep the setup… if you don’t, save yourself some money!
