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
@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 ??

Far from having ‘dissolved itself‘ I sincerely hope that this thread might lead serious designers to reconsider whether rather than using a low end, convenience consumer interface with all its known foibles to transmit high quality audio, one might usefully revisit more appropriate formats (optical, I2S, AES/EBU) to improve on what is at best an unacceptably wide range of outcomes with USB; I also note with a degree of puzzlement that members of the ‘bits are bits’ school of sitting on your ears are alive and well

Respectfully, it kinda has.  Its' just another "I'm right you're wrong" (not directed at you).  Armchair experts everywhere.

Its fine to not like USB, or.......but keep in mind it's an individual use case.  This thread isn't going to change a designers mind to all of a sudden say, "hmm someone on the web doesn't like USB, I should probably use spdif"
The amount of info with issues, aka " with all its known foibles" on every interface is easily documented / found.  i2s, AES etc.. ALL have (potential) issues/shortcomings, given how its implemented in certain products.  It's either done right or not.  Again, implementation has been repeated ad nauseam.  That's the bottom line on how I see it.

I'm not trying to change anyone's mind, why would I care, whatever floats your boat.   Everyone's use case (which is pretty critical in the overall scheme of things) is different and It's really about having a mature discussion.