thanks for this information!! very helpful in putting all the pieces together.
to clarify: i am referring to ethernet transmission of an audio file itself (e.g. flac, wav, mp3), NOT the transmission of an audio file that has been decoded and rendered into a timed, digital bitstream... the later is now what i believe swenson is discussing and this distinction was the source of the confusion generating my initial question.
as a concrete example, consider an MSB DAC with an MSB network renderer module... according to MSB:
The renderer receives the audio file from the media server and creates a digital music stream, where it’s sent and converted into analog audio by a DAC...
The renderer needs a low jitter clock and clean power, provided by the MSB DAC’s master Femtosecond clock and its multi-rail isolated linear power supply.
see this link for a great overall description of the network topology:
http://www.msbtechnology.com/renderernetwork/
in this topology, an encoded audio file is sent via ethernet to the renderer module which then decodes the file and converts it into a timed, digital bitstream using the DACs onboard master femtosecond clock. here, there is no re-clocking as the MSB DAC is creating the timed, bitstream itself.
i agree that the re-clocking of a timed, digital bitstream
can be influenced by upstream clocks with the amount of such influence, if any, being DAC specific. however, this still leaves open the question of whether ethernet is used to transmit this type data... anyone know of a DAC that accepts a timed, digital bitstream over ethernet? my understanding is that rendered files are usually send to a DAC via optical or coaxial s/pdif, aes/ebu, usb, etc.
finally and to further clarify, the above discussion is only concerned with data transmission and is separate from a discussion of electrical noise such as RFI, EMI, etc. that can be transmitted alongside the bitstream.
Hi aKnight (sorry I don't know your actual name),
It took me a while to read and understand your comment above, but upon reflection, no, I don't think there are any differences with the examples I gave above to your situation or the situation or that John Swenson was discussing. In fact, I think they are one and the same.
Just to start off, all the info I posted above was specifically speaking to your your point above:
"I am referring to ethernet transmission of an audio file itself (e.g. flac, wav, mp3)". Well, that file has to go to....something, either an endpont,network bridge, or render, or if it has an RJ45 port, the DAC itself.
Its exactly this tranmission of a digital audio file on some form of storage media on a computer, server, NAS, etc., to a destination, e.g., an endpoint, renderer, network bridge, or DAC that Swenson was specifically referring to. The ethernet (or USB) transmission from any point A to point B IS a bitstream, and this is exactly the situation that a number of the problems that John Swenson described occurs. The PHY chip in an Ethernet subsystem pulls the digital file from the MAC layer, and sends it as
analog square waves along the Ethernet (or fiber) cable to the to the downstream Ethernet port, whether that port is an endpoint, renderer, network bridge, Ethernet suppored DAC,
whatever. From Wikipedia:
"the Ethernet PHY is a chip that implements the hardware send and receive function of Ethernet frames; it interfaces between the analog domain of the Ethernet's line modulation and the digital domain of link-layer packet signaling.
The very same functionality and attendant problems with EMI/RF noise, clock phase noise, galvanic isolation, etc., also applies to the USB/SPDIF path from the endpoint, renderer, network bridge to a DAC.
So, when you say: "NOT the transmission of an audio file that has been decoded and rendered into a timed, digital bitstream", with all due respect, I think this description is incomplete, and thereby, inaccurate. Any time you send a request to a digital system to send a digital file to some other "place", there is a conversion from the digital domain of link-layer packet signalling via the MAC to either a Ethernet or USB PHY chip to convert it to
analog squarewares to send it to its respective destination; where its received by the downstream receiver/PHY chip. Moreover, any device that tranmits digital-sourced data, whether it be a cable modem, router, music server, NAS, Ethernet switch, renderer, network bridge, or DAC, has a clock. If the upstream clocks for the "generic IT stuff" (the router, music server, NAS, Ethernet switch) are sh*tty, then you are going to have clock phase noise added at every stop along the path from one device to another. There's only so much the clock at the renderer or DAC end can do to fix these dirty fingerprints, as John puts it.
Also, as far as I understand it, the renderer/streamer/network bridge does not do any decoding, that is the solely function of the D/A convertor in the DAC.
Lastly, I think the information from MSB is written in a way that is misleading with respect to the accuracy of what is actually happening, functionally-speaking. From what I've read above from the MSB description, I don't think the renderer is decoding anything, unless it doing some sort of transformation that is not described, like converting PCM to oversampled DSD, etc. And the renderer doesn't correct the timing, the FEMTO clock sub-system of the DAC chip does. From what I can gather above, the description from MSB above is both confusing and inaccurate, unless my understanding of the what renderer is doing is completely off-base. The written description above looks like it was written by a marketing person, not an engineer like John Swenson.
If you still have questions, you should take them directly to MSB, because I don't understand exactly what MSB is saying above; I find it ambiguous and misleading.
Sorry I can't be of more help...
-Stephen aka PC
