Phil, thank you so much for your answer - that explains everything to me 
greetings
Kasza, I think my experience may be relevant here. I also have the DCS Rossini Apex DAC and a clock. For the last 2 years I was using a Nucleus+ to stream all my music. This was a great server, no doubt. About 2 months ago I upgraded to the Taiko Audio server. The difference for me was night and day, again, my system only…. The bass was much more solid, sound stage much wider/deeper, all the things everyone likes to talk about in these forums. That said, I believe a lot has to do with the significantly better power supply in that server. Also, I’m a using Jorma Statement PC into the server as well as their USB cable…all of which are at a different price point than Nucleus+. Is this server noticeably better in my system, you bet! But is it a fair comparison, not really…. If you can, I would encourage you to do a home trial if possible. That’s what I did. I also tried the Nordost QSource Linear Power supply into my Nucleus which for me was a big upgrade as well. In the end, it still wasn’t as good at the Taiko (even thru a USB connection)…but if I didn’t end up getting the Taiko, I would have definitely added the high quality LPS into my Nucleus!
1 Like
As noted, this topic has been discussed before. dCS buffers incoming data streams to reduce/eliminate influence on data packets from the server. Many on this forum use the Roon Nucleus in Rossini/Vivaldi systems. I personally am skeptical of “high end” servers but to each their own : )
Rossini Manual:
"Set to On, the digital data is delayed before being presented to the Ring DAC – this is
the usual setting. The delay is 0.72 seconds with 44.1kS/s data and 0.16 seconds with
192kS/s data. The delay gives the DAC time to detect changes in sample rate or clock
frequency and mute before the change causes audible clicks or other noises.
Hi,
This is actually only the Ring DAC buffer too … if you’re pulling data via Ethernet there is a totally separate buffer that is built into the networking hardware that can hold several minutes of audio (depending on sample rate and bit-depth) that the audio is then played from.
Best regards
Phil
4 Likes
Thank you for that additional clarification @Phil. I always thought that was the case but couldn’t find it in the documentation! : )
If it’s not in the documentation, a search here on dcs.community usually gets you the answer 
3 Likes
Thanks @Anupc. That reminds me of an old entry of class notes from MIT: “Course was very complete. What was not covered during lectures was covered on exams.”
: )
3 Likes
Good one! I’ll have to use that quote sometime! 
1 Like
From the usage side (controls, management, search and other functions in the roon), is it identical on the Innous, 432 Evo and Nucleus? Another question: Is the program written for Nucleus the same as for other devices? (I am asking about the control, but most of all about the sound quality)
I will ask otherwise: if I use, for example, the 432 Evo via USB, what will I lose in the signal? I mean, what won’t my Rossini do with the signal? I want DCS to have a big influence on the signal and the source / server as little as possible, because that’s why I bought a very good quality streamer / DAC to use it as much as possible. What’s the difference between usb input vs ethernet? What will I lose when using usb?
You’ll lose the ability to control everything from Mosaic for one thing…
Phil
Phil, but I only use the roon. Will I also lose something? The most important thing for me is the quality of the sound and the control by the roon as I do now by the Nucleus
In my dealers reference system we have tried many streamers, streaming with the Rossini works great, but when you get to the level of Aurender N20, W20SE or Grimm MU1, streaming with the Rossini cannot keep up.
I know this will be a difficult statement on this site.
In my own system I continue to stream both with my Rossini and Aurender N10, both are at the same level imo, tiny flavour differences.
1 Like
Hi,
Yes, if you have the server connected via USB then Roon won’t control both the server and the Rossini as a single device and it will be a pain to control.
I would strongly advise using the Rossini over Ethernet but of course there is nothing to stop you trying USB and deciding for yourself.
Phil
Hi @Phil, thanks again for chiming in and enlightening us with details from inside dCS.
You wrote something previously that I’ve been thinking about more and thought I would inquire.
In your response to me about buffering, you stated: “if you’re pulling data via Ethernet there is a totally separate buffer that is built into the networking hardware…”
This was a very specific statement. Does this mean that dCS does not buffer incoming data if it comes over USB? Is that the reason why dCS recommends Ethernet over USB?
I was thinking: If both data streams are buffered, then why would there be (or how could there be) a difference…
Thank you!
R
Hi,
Both USB and Ethernet are buffered but in different ways and the data transfer part of the playback process is different too …
It might be easier (although not accurate but this is just an attempt at a simplified visualisation) to think of Ethernet playback as more of a “pull” proposition whereby the player is in charge and will try to pull data into itself as quickly as it can until the players buffers are filled (or the source device for whatever reason is unable to provide more data) and the player can then generate its own timings and manage playback whereas when playing back vis USB it’s more of a “push” proposition where the source device is in charge of controlling playback and pushing data to the player so the player has a much more limited window to work within and has essentially to match timings overall to the source.
It’s not an accurate analogy but it’s close enough to (hopefully) get the idea - it’s like when I was learning to drive (many years ago) my fathers instruction on setting off from a standstill was “as you lift your foot off the clutch press down the accelerator” … it’s “right” as a top level description (as anyone that drives a manual will understand) but lacks all the minute details of biting points and balancing clutch and accelerator etc. that actually make the process happen.
4 Likes
Just my two cents (in additional to Phil’s comments).
Both the USB and the Ethernet interfaces on dCS are bit-perfect transport ports even though the two use very different protocol stacks - ALSA for USB, and TCP/IP for Ethernet (both within the Linux Kernel on the Streaming board).
However, where Ethernet enjoys galvanic isolation (native to the Ethernet standard interface with a differential coupling transformer), the USB does not.
2 Likes
Thank you @Phil and @Anupc, this helps me understand this better!
@Anupc : forgive me if this is a “dumb” question, would the galvanic isolation properties of Ethernet that you describe remain relevant while in the data stream is in the dCS playback buffer?
Hopefully save Anup some typing…
(…and I hope you don’t mind me replying to this Anup…)
The Ethernet isolation manages induced noise on the Ethernet connection and prevents it entering the circuitry of the streamer so in that respect it reduces / removes the effect of externally generated noise but it doesn’t improve the data integrity of the data being used by the streamer (both USB and Ethernet are “bit perfect” transports due to their native underlying protocols) and in itself doesn’t “improve” or otherwise effect the data that is in the audio buffers. It just puts a block on a potential source of noise entering the streamer.
Phil
1 Like
(Of course I don’t mind Phil )
To put it simply though, with packet interfaces, galvanic isolation (or lack thereof) at the physical layer doesn’t affect the actual payload (the PCM/DSD data encapsulated within the transport protocol stack).
This payload is delivered/decapsulated on the St[r]eaming board; which is a complete Compute platform on its own, with an ARM SoC and associated RAM (the buffer in your original question) etc.
1 Like