USB sucks

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’m pretty sure that you will get an equally wide range of outcomes using these other formats.

And reading your initial post, the problems you had with getting a reliable connection are not inherently USB problems since millions of others have absolutely no issues getting a reliable connection. The fact that you finally got it to work with a particular USB cable tells me something else was amiss. The best sounding connection we can debate, but not being able to get the source to communicate with the DAC via USB is highly unusual.

I also have an Antelope DAC that I am extremely happy with although I do sometimes have to reboot my computer or the DAC to establish USB communication so maybe they do work better in a pro audio situation with that gear versus audiophile servers,  and I sometimes have to toggle the internal word clock from lower rates to the maximum rate to get sound output, but a minor inconvenience for the wonderful sound at a reasonable cost.

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.