USB audio cracked... finally!

[scan80269]

There are two main transfer protocols covered in the USB 2.0 specification: bulk transfer mode - used mainly by storage devices such as flash drives and external USB hard drives, and isochronous transfer mode, using by streaming devices such as webcams and modern DACs.  Specifically, DACs tend to use "isochronous transfer mode with asynchronous feedback" for digital audio data transfer over USB.  This transfer mode does not support data re-sending upon error detection by the receiver.  It favors predictable data transfer bandwidth and latency over data integrity.

 

I suspect there is a fair amount of unavoidable periodicity in this isochronous transfer mode.  For example, packet rate is 8KHz.  In contrast, the bulk transfer mode, by not guaranteeing transfer bandwidth or latency, may actually be less periodic in the way the data fly over the cable from sender to receiver.  Is it possibly what Peter has figured out, by making his DAC support only USB bulk transfer mode, along with a deep FIFO data buffer to smooth out the extreme irregularities of USB data arriving at the DAC?

 

I also wonder if a USB cable designed to intentionally affect the error rate of USB data transfer can affect the sound.  The transfer protocol is negotiated between the USB host controller and the USB device (e.g. DAC), and the USB cable being a passive design cannot influence the protocol negotiation in any way, but the cable is in a position to alter data transmission integrity.  Is this perhaps a case where the most spec compliant USB cable design (e.g. 90 ohm differential impedance) may not translate to the most desired sound???  If a USB cable can induce a certain amount of random data transmission errors the increased randomness in how the data goes over the cable *may* be sonically beneficial?

 

Just thinking out loud here...

 

[scan80269]

27 minutes ago, mmerrill99 said:

Yes, bandwidth limiting that affects the signal shape seems to have an audible effect - this includes USB cables which are not of sufficient bandwidth.

 

If we consider USB high speed is 480Mbps or 480MHz fundamental frequency & to represent a half decent square wave requires at least 3 harmonics (some say 5 harmonics) we have a requirement for passing 480MHz X 3 = 1.44GHz bandwidth requirement for a cable or if you want to consider 5 harmonics necessary for a good squarewave then 480X5 or 2.4GHz badwidth cable is necessary!

I found this statement in the USB 2.0 Specification, for high-speed (480Mbps) transfer rate:

 

For a hub, or for a device with detachable cable, the 10% to 90% high-speed differential rise and fall times must be 500ps or longer when measured at the A or B receptacles (respectively).

 

The differential signals on the D+ & D- lines don't need to be as square as possible.  The rise/fall times need to be fast enough to pass well defined eye pattern requirements.  In modern motherboard designs with USB ports, there are often design trade-offs between USB signal integrity and EMC compliance.  Insertion of inline common mode chokes are used to mitigate EMC issues but can lead to waveform distortions that can affect transmission integrity.  These issues are observable via eye pattern measurements.

 

Alterations of USB signal rise/fall times (e.g. by a cable) can lead to timing differences at the receiver, since USB employs embedded clock technology (i.e. no separate clock wires alongside the data wires).  The USB PHY on the receiving end has to work harder to retrieve the bit stream in real time if the incoming USB signal integrity is poor.  This is now quite well understood, albeit rather recently.  There's an optimum range of rise/fall times, and anything too slow or too fast will be detrimental (in different ways).

 

So I don't doubt different USB cables can result in different sound.  Immunizing a DAC against the effects of a USB cable connected to it has not been trivial and there hasn't been a lot of success cases AFAIK.

 

[scan80269]

1 hour ago, mmerrill99 said:

If I can answer for Scan - I believe what he means is not that the audio clock is embedded in the USB data packets but rather that the USB specification states USB frames are sent every 1mS & high speed microframes are meant to be sent every 125uS i.e 8 microframes per 1mS frame or the 8KHz periodic current burst sometimes reported. There is a certain +/- tolerance on these timings in the USB spec. The PC's USB clock usually times this but in asynchronous USB the USB receiver's local USB keeps it's local buffers half full by sending back signals to the PC about how much data should be in the next microframe.   

Thanks, mmerrill99!

 

Yes, USB as a transport for digital audio (from computer/streamer source to DAC) differs from other digital audio transports like I2S, S/PDIF coax & Toslink optical, AES, etc. in that with USB, there is no audio timing whatsoever in the data packets running over the cable.  Every DAC that has a USB input must re-clock the digital audio stream received over USB into an audio clock domain of a power-of-2 multiple of either 44.1KHz or 48KHz depending on the sampling rate of the audio stream being transported.  For example, the 22.5792MHz audio clock reference is used to re-clock an audio stream carrying 44.1K/88.2K/176.4K/352.8K sampling rate (including Redbook 16/44.1K CD audio).  This re-clocking is often done with a block of digital logic implemented with an FPGA such as from Xilinx or Altera.  A data stream buffer (FIFO) is used to tolerate disruptions or underfeeding of audio data coming from USB.  Over-sampling of the audio ahead of the digital-to-analog conversion can involve the use of custom DSP hardware as well.

 

The USB receiver HW in a DAC, e.g. XMOS chip can be a significant source of electrical noise, so galvanic isolation of the USB receiver section from the rest of the DAC has become increasingly popular in newer DAC or DDC designs.  Technically it can be more challenging to design a DAC to sound as good with its USB input than with other digital audio inputs (that carry embedded or explicit audio clocks), but there's no compelling reason to summarily dismiss USB as an inferior digital audio transport.  Good (or bad) implementation can easily make a larger difference than the type of transport interface.

 

[scan80269]

29 minutes ago, pkane2001 said:

 

That's right. And that's why I asked the question. If the timing of the actual audio samples is driven by an on-board clock, how does the timing error in the USB packets affect this clock? How does the error in timing due to a poor 'eye pattern' or HF rolloff of the square wave edges result in anything audible after the samples are collected in a FIFO buffer and then doled out using the onboard clock? This question is important in explaining how a USB cable might or might not affect the analog domain.

 

Of course, if timing errors and square wave distortions are not the issue, and instead leaked noise from the PC side is the problem, then perhaps a better isolation between the PC and the USB receiver would eliminate the need for fancy cables. 

 

I'm going to take a swag at answering your questions, though I humbly profess that I'm far from being a "know-it-all"...

 

In theory, signal integrity of USB signals entering the USB front-end of a DAC should have no effect on the digital-to-analog conversion and downstream analog output circuitry.  In reality, the quality of the USB signals arriving at the DAC USB receiver will greatly affect how hard the USB interface chip (e.g. XMOS) has to work to retrieve the bitstream.  The more active a block of digital (or digital/analog hybrid) logic works, the more power hungry it becomes so it dumps more electrical noise onto the power & ground planes it sits on.  Unless very well isolated, this electrical noise can make its way to the D-to-A conversion circuitry and induce increased jitter into the conversion, which can then be heard as degraded sound at the analog outputs.  John Swenson has explained this phenomenon in great detail.

 

A good USB re-clocker should greatly reduce the audible impact of the USB cable, though as John may have also indicated, the key word is reduce, not eliminate.  With increasing evidence that the USB data signals (D+ & D-) can carry noise in addition to the intended USB signal, coupled with USB receiver PHY's ability to attenuate common-mode noise but not differential mode noise, we probably have a scenario of some amount of noise (mostly differential) getting through to the clock and data recovery logic sections, thus inducing more activity and noise.

 

Galvanic isolation can help block noise conducted over the +5V Vbus and ground wires of a USB cable, but differential noise carried on the USB D+/D- signals is hard to block.  One good technique used by many USB re-clockers is to deploy a USB hub chip to receive the noisy USB signal from the upstream PC or streamer, and use one of the downstream-facing USB ports of the hub chip to drive the DAC with a cleaner copy of the USB signal.

 

As one of many interfaces for transporting digital audio, USB has merits of ease-of-use, easy to implement galvanic isolation, easy to implement re-clocking (e.g. with a clean powered hub chip).  From the technical point of view, I'm not surprised by the variety of USB tweak devices that have sprung up in the past few years.  These devices are relatively straightforward to design and implement, at least as compared to devices of equivalent functionality for interfaces such as S/PDIF, AES, I2S.

 

Based on recent understandings of what issues the USB interface of a DAC can suffer, I believe there will be newer DAC designs with integrated galvanic isolation, re-clocking, etc. that will render most of the existing USB tweak devices redundant.  It should only be a matter of time.  A few excellent DACs today (Phasure? Berkeley?) are already so good they don't benefit from the USB tweak boxes.  BTW, my Auralic Aries Femto / Vega DAC combo has repeatedly failed to benefit sound wise from any USB re-clocker (including W4S, UpTone Amber REGEN & ISO REGEN) or isolator (Intona) inserted between them.  I'd say overall, many current brands of DACs have a bit of catching up to do...