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.
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.
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?
(…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.
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.
Thank you both. I really appreciate the detailed explanations. Now I understand that both transport protocols are bit perfect and the issue is introduced noise, as opposed to lost data through transmission. Thank you!!!
This topic is interesting to me because - and I understand Phil may or may not want to comment on this - MSB recommends the opposite. MSB recommends their Pro-USB interface over their own Network Renderer (Ethernet) module for both the Reference and Select DACs (the top 2 models). This is curious.
For clarity, I am a long time dCS owner (Puccini->Rossini), and have never owned MSB. However, I find it very interesting that two of the top DAC manufacturers in the world recommend opposite approaches on data transmission. Why would this be?
It kind of make sense; if I understand MSB’s ProUSB solution correctly, it provides for optical isolation via a USB-to-ProISL conversion, with what looks like standard SFP modules (I’m guessing ProISL is in fact some form of GbE encapsulation).
Whereas with their Ethernet module, they only get the standard galvanic isolation that comes from the Ethernet’s differential port transformers.
)