USB sucks


USB really isn‘t the right connection between DAC and Server: depending on cables used, you get very different sound quality if the server manages to recognise the DAC at all. Some time ago I replaced my highly tuned Mac Mini (by now-defunct Mach2mini, running Puremusic via USB) with an Innuos Zenith Mk3. For starters I couldn‘t get the DAC (Antelope Zodiac Gold) and server to recognise each other, transmission from the server under USB2.0 wasn‘t possible because the server is Linux based (mind, both alledgedly support the USB2.0 standard) and when I finally got them to talk to each other (by using Artisansilvercables (pure silver) the sound quality was ho-hum. While I understand the conceptual attraction to have the master clock near the converter under asynchronous USB, the connection‘s vagaries (need for exact 90 Ohms impedance, proneness to IFR interference, need to properly shield the 5v power line, short cable runs) makes one wonder, why one wouldn‘t do better to update I2S or S/PDIF or at the higher end use AES/EBU. After more than 20 years of digital playback, the wide variety of outcomes from minor changes seems unacceptable.

Since then and after a lot of playing around I have replaced the silver cables by Uptone USPCB rigid connectors, inserted an Intona Isolator 2.0 and Schiit EITR converting USB to S/PDIF. Connection to the DAC is via Acoustic Revive DSIX powered by a Kingrex LPS.

The amount of back and forth to make all this work is mindboggling, depending on choice of USB cables (with and without separate 5V connection, short, thick and God-knows what else) is hard to believe for something called a standard interface and the differences in sound quality make any review of USB products arbitrary verging on meaningless.

Obviously S/PDIF gives you no native PCM or DSD but, hey, most recordings still are redbook, anyway.
Conversely it is plug and play although quality of the cable still matters but finally it got me the sound quality I was looking for. It may not be the future but nor should USB, given all the shortcomings. Why is the industry promoting a standard that clearly isn‘t fit for purpose?

Finally, I invite the Bits-are-bits naysayers to go on a similar journey, it just might prove to be educational.
antigrunge2
As for jitter from servers and transports.. Asynchronous transfer is designed to eliminate that. The DAC asks for data packets at its pace and clocks them on down the line using its internal clocks. Any jitter from the source is therefore disregarded so if you hear a difference using devices as above, in theory it is not because they reduced jitter. That said, I don’t doubt you hear something. I’m just saying that attributing it to jitter flies in the face of everything we know about how this stuff all works.
+1.  It's quite possible that a device that purports to be a USB reclocker (any device that receives and retransmits USB is a reclocker) is reducing noise on the USB signal to an audible degree. But the notion that this is because it has less jitter on the USB connection makes no sense. 

I believe that there are still a lot of DACs on the market that sound better using legacy interfaces (spdif, toslink, aes3) but I contend that this is either because the source of these signals (transport/streamer) has a better clock than the DAC, or the DAC has a particularly poor USB implementation. 

There is no technical reason why a DAC can't be implemented with a USB interface that outperforms legacy interfaces. SPDIF, Toslink, and AES3 all have an inherent flaw in that they are prone to jitter because the clock is embedded with the data. No matter how much you spend on cables, the connectors themselves introduce impedance discontinuities which create reflections which interfere with the waveform. 

I'm not saying that legacy interfaces can't delivery excellent results. But from an engineering perspective, the cost to do so exceeds (perhaps significantly) the cost to achieve similar performance from USB (or Ethernet). I think it's only a matter of time before the industry has dropped the legacy interfaces in favor of USB (or some future asynchronous digital transport interface).
@herman 

Since you like the Antelope DAC: may I suggest you try it on S/PDIF or AES/EBU? With the Schiit EITR the sound is far superior to USB all the way through. And by the bye: the Intona substantially improves the straight USB connection compared to a split lead all silver USB cable. I believe that the effects of noise (either from 5v leakage from the server or all sorts of airborne grunge) on the DAC’s receiver implementation and clocking is still not well understood.
@herman  As a programmer and electronic interface design engineer, you're not "locked" into using isochronous mode: You have bandwidth and buffers so if i can transfer 500 MBps+ (using SATA SSD = 4 Gbps+) of data without error (well, if there are errors, they are corrected), it should't be a problem to playback music!

The USB spec has a enough protocol sophistication to handle many things.  Of course, computer setup, minimal cabling care (lenght, compliance, etc) and other evidences must be met.

Want to test cables for performance?

https://www.passmark.com/downloads/USB3LoopbackPlugUsersGuide.pdf
It's about 100$ so for those who want to spend big money on cables, that shouldn't be a problem.
On the Linux platform, you can hook to the kernel and you have a rich set entry points / data to monitor USB for performance and errors.  Windows / Mac should have a couple of tools too (i'm a Linux user, so not sure about those 2).  So imagine testing a USB cable with NVMe to USB adaptor and pushing gigabits of data through it.  If your cable is not good, it'll show.

cp /dev/nvme0n1 /dev/null

(copy from external NVMe USB drive to NULL = Max Speed of the source).  Of course it's bulk mode!


As for transfer mode, here is a user question and a response from usb.org:

https://thepenguin.eu/2018-01-19-audiophile-usb-cables/

USB transmits information digitally. Bits are either received correctly or not received. What a bit looks like on the wire has no effect on quality if the bit is received correctly. If a bit is not receive correctly, error checking in USB protocols will flag the error in data transmission. Jitter is not a cable problem. Jitter is a transceiver (PHY) issue on the devices. Can bits get scrambled within a cable assembly on occasion? Yes, primarily due to EMI but this is highly unlikely -- more on that later. Is occasional data scrambling a problem for audio/video?
Maybe. The answer depends on the hardware receiving/rendering the data. USB supports isochronous transport which is a timely delivery of data. The isochronous transport has guaranteed bandwidth on USB. Isochronous protocol, however, does not support error recovery. In other words, if data is flagged as an error by the receiver, there will be no attempt at data retransmission.
So if the receiver is using the isochronous protocol, then there can be errors in data. Most webcams use the isochronous transport. High-end audio/video equipment that does not mandate real-time delivery of data should not use the isochronous transport because accurate data delivery is not guaranteed.
USB also supports bulk transport. The Bulk transport shares bandwidth and timely delivery is not guaranteed. Bulk protocol does have error recovery and errors in data will be retried. If the receiver uses the bulk USB protocol, then there will be no errors in the data.
This is why USB mass storage devices always use the Bulk transport. Most USB audio/video devices use the bulk transport because real-time delivery of the data is not necessary. Bulk audio/video devices will buffer data before rendering it.
I can think of only two situations where the audio/video will be disturbed when rendered: 1) If the host is busy performing IO to other USB devices, or 2) There are errors in data transmission where continual retries cause buffer under-run to occur.
The second point could be cable related -- it could also be poor hardware design of the host or peripheral as well. The USB Bulk transport works very nicely for audio and video because data is accurately delivered. Now onto cable quality. A cheap USB cable will work perfectly fine in the vast majority of home/office environments. All USB certified cables use certified connectors and are shielded, have minimal skew on the data lines, and meet criteria regarding impedance and voltage drop. If the environment is extremely noisy with EMI, then a better shielded cable may be necessary. Usually relocating the cable or power strips will suffice to mitigate EMI. Personally, I would never recommend anyone buy an expensive USB cable unless they are experiencing problems not related to their hardware and there exists definitive suspicions of environmental interference.
I do always recommend that the cable purchased be USB certified which provides assurance that the product is properly designed for USB. Using USB certified audio/video equipment also assures that the USB signal quality and other packet parameters of the transceiver meets specifications. Of course, all of the above is premised upon properly designed and functioning hardware. Regards, Mark Paxson USB-IF Compliance Administrator TechAdmin@usb.org


Most USB audio/video devices use the bulk transport because real-time delivery of the data is not necessary.
This simply is not true if "most" includes the topic at hand... USB DACs? 

 As a programmer and electronic interface design engineer, you're not "locked" into using isochronous mode: You have bandwidth and buffers so if i can transfer 500 MBps+ (using SATA SSD = 4 Gbps+) of data without error (well, if there are errors, they are corrected), it should't be a problem to playback music!

It doesn't matter what could be done. It matters what is done, and since asynchronous is what is done, errors are not corrected. End of story.
@antigrunge2 

Since you like the Antelope DAC: may I suggest you try it on S/PDIF or AES/EBU?

fair enough, but how do you generate the signals? There are a few ways I know of, Ethernet to spdif with a

  • Raspberry Pi HifiBerry seems like a step back, maybe not
  •  DCS network bridge, $3500 , more than I paid for the Antelope
  • $20K+ Aurender W20, not an option for me

Of course there are USB to spdif but we are trying to eliminate USB. 

suggestions ??