|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
199.46.200.232
In Reply to: RE: DACs using SPDIF are broken by design posted by Tony Lauck on October 20, 2014 at 09:22:54
Like you said, S/PDIF is flawed by design. I can think of at least 3 major issues with it. Communication is simplex (unidirectional) without flow control and therefore the DAC must have a variable clock, and it must be synchronized to the clock reference provided by the transport using a PLL. Second, the data is self-clocked via Manchester encoding, which was never meant for transmission of a high quality clock signal. Finally, it's single ended, so there will be ground loops and greater susceptibility to EMI and RFI. Given this kind of interface, I think it's unreasonable to expect the DAC to be immune to differences between transports and digital cables. If the audio industry were to adopt an interface standard that avoids these three problems, then I would agree to blame the DAC if transport differences persist.
I2S only addresses one of these 3 flaws, by separating clock and data signals. It's still simplex and still single ended. Likewise, AES/EBU only addresses one of these 3 flaws. It's balanced, but it's still simplex and encodes the clock with the data. And Toslink provides galvanic isolation, but it's also simplex and encodes the clock with the data, not to mention that a lot of Toslink connections are low bandwidth. It seems like all of these transmission standards were created before the importance of clocking in digital audio was well understood. It's a mystery to me why they are still used in high end products.
I think it's best to locate the clocks in the DAC right next to the DAC chips, which requires flow control by the DAC and therefore duplex communications. I'm not aware of any audio specific digital interface standards which support that, so we're stuck with general purpose computer interfaces like Async USB, FireWire, and Ethernet. These have their own disadvantages. Async USB and FireWire include DC power and ground, so they aren't galvanically isolated. Ethernet over twisted pair gets the physical connection right, but requires too much processing to be a good digital transport to DAC connection.
Unfortunately, the only interfaces that tick all the boxes seem to be proprietary.
Follow Ups:
good set of comments, although usb transfer still requires clocking to produce the 44.1 and 48k related signals and many of them are not that good.
A lot of the noise is due to commercial inter and personal prejudice.
The sdif interfaces in my dCS converters are really good and impedance matched.
What DCS units do you have?
"Asylums with doors open wide,
Where people had paid to see inside,
For entertainment they watch his body twist
Behind his eyes he says, 'I still exist.'"
I2S comes in two flavors: clock at source and clock at master. It's the same signals in either case, the difference is where the clock itself is located and which way the clock signal travels on the wire. If the clock is at the source then (assuming all the wires are the same length) there will be no skew problems between the clock and the data lines. The problem is that noise on the clock line translates via limited risetime to a jitter source at the distant end. If the clock is at the transport then this noise jitters the DAC itself, causing distortion. (However, this jitter is at least uncorrelated with the signal, unlike with SPDIF.) If the clock is at the the DAC then noise on the clock line doesn't affect the DAC. The problem might be skew, but this can be minimized by limiting the round trip time to a fraction of a bit time. Alternatively, and this has been used as far back as the 1960's in "super computers" the cable length can be fixed so that round trip time is an integral number of bit times.
I2S was proposed as an on-board interconnect, originally TTL levels. If it is used across a cable there are electrical issues that must be addressed, but the signals can perfectly well be sent in a balanced fashion, reducing noise coupling.
AES can be used correctly, with the clock at the DAC for playback and separate cabling used to send a clock signal to the transport. In this regard, it is almost as good as I2S, since any jitter on the incoming data lines caused by the Manchester coding is lost when the signals are latched by the local clock. (No need for phase lock loops.) I2S over cables is not standardized, so some implementations probably provide balanced signaling.
There is an operational benefit for placing the clock at the source, even though this is sonically inferior. The clock signal identifies the sampling rate. When the clock is placed at the sink then an out of band channel is needed to select a sample rate that matches the source, assuming that the source is not willing to do a sample rate conversion to a common rate. In some professional systems, separate datacomm links have been used for the out of band channel. With USB, not only is there bidirectional data flow, but there is also the ability to send control and status signals as needed to deal with housekeeping factors.
Since the relevant signal quality and jitter issues were known at the best communications and computer laboratories as far back as the 50's and 60's the situation in audio reflects ignorance on the part of the designers or cost pressures that are appropriate to mass market products, but just plain wrong when used to design "cost no object" products, which is what the "high end" purports to do. I say "purports" because some vendors sell expensive audio jewelry.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: