ok, little strange…
I have a NAS, roon server and a streamer connected with Cisco switch. Between roon server and switch I have now the Chord Epic streaming cable.
Chord Epic has an arrow that points from the source. Afaik is roon a source and target, right (means receives and sends file)
So is the arrow here (means direction) not relevant?
ok, little strange…
Those packets could get confused
I’d try it both ways and see if you notice any difference.
Ethernet directionality really makes me laugh a lot it’s not one way traffic in any implementation. I believe it’s likely the ground is connected at one end and not the other and for some reason they believe this has an affect. Roon is source in this scenario to your streamer I would work that way first so arrow is to the switch.
Clearly as suggested above Ethernet by its function is bidirectional, with cables on duplex leads dedicated for each direction.
However some cables have a grounding wire that is connected only at one end, and so you might want to check whether your switch you are connecting to is grounded, and ensure the grounded end is connected to that. Other than that there is by no definition directionality.
The reason for that is that I try to improve roon’s SQ…I put in a Sbooster PSU and a Chord Epic cable for roon server (a sonictransporter i5)…It’s still not possible for me to get roon’s SQ on par with native UPNP streaming.
I miss the much more open and airy highs and the much bigger sound stage vs UPNP native. Roon limits the musical flow. Didn’t realize that with the ND555 but now with dCS it’s really obvious. Last thing I can do is changing the roon core server (maybe a nucleus).
Is the ST supplying UPnP and Roon core to the same streamer? Or is UPnP running on different hardware?
The upnp service is on melco.
I assume the DCS is the streamer here ? Or are you using the Melco into the DCS. It’s not clear what your chain is for both so trying tk establish a baseline here. If it’s the DCS then I would try running UPnP and Roon on the ST to see if the difference is still there. If it is then the different hardware maybe the difference. Also if the Melco is in-between the streamer and the ST then Roon is not getting the same path at all. As data will be pulled from the Melco to Roon core then back out to Melco and out to the streamer. Where as UPnP will be direct through no extra hops. Which could account for the difference. This is why I suggest to try both on one server to see.
Many Thanks CrystalGipsy!
You’re right- DCS is the streamer. I tried now to run upnp services and roon on ST.
Upnp done with Melco sounds much better- so indeed, it could be ST or the extra hop through the network!
Well technically underneath the covers the UPnP and RAAT media transfers are effectively identical and so no difference in SQ from the transport itself.
If you have difference in SQ then I would look at the end point… as that is providing the difference… perhaps in a way like difference between WAV play out and AIFF play out .
Check in with DCS to, they have been a Roon partner along time and they might be able to advise.
Simon I’m not sure about same transfer upnp vs raat…
Upnp seems async- means the controlling is not in the same “path” like music afaik.
raat seems sync- means music and controlling is in the same “path”- that causes more network traffic since music goes from nas-to roon-from roon-to streamer.
When I looked on the line RAAT media transfer, like UPNP, it is simply PCM transfer in TCP between the server and client.
You might be referring to synchronisation of multiple end points for synchronous play out and synchronising endpoints with each other… but that is quite separate from media transfer. The point that Roon state is that there is no standardised way of doing it in UPnP (Naim have developed their own system within their closed ecosystem) and so they, Roon, have developed a consistent way in RAAT within their ecosystem. But again as I say that is not linked to media transfer… and both use the same network ‘paths’ or flows.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.