[Pez]

Technical Notes

USB Audio Gremlins Exposed
Beyond 1s and 0s

1. Bits are really just Bits?

1.1 Background

A common sentiment heard in the context of digital audio is that ‘Bits are Bits’ and as long as data makes it from A to B, different or ‘premium’ cables and other ‘tweaks’ cannot have any effect in the physical realm and are purely imaginary.

While this view has long been debunked where SPDIF and AES-EBU connections are concerned (not least by Stereophile and others), it is often considered a tenet of faith for USB audio - especially asynchronous USB Audio - that ‘Bits are Bits’ and any differences arising from cables, operating system tweaks and other items are purely imaginary (delusionary?).

Yet just as differences in SPDIF Cables and/or sources as well as DACs (and their combinations) can be shown to produce not just audible but reliably measurable differences, USB audio is subject to its own set of limitations and problems.

1.2 Asynchronous USB audio to the rescue?

As far back as early 2001, computer-based audio with asynchronous USB audio proved it was possible to outperform SPDIF and/or AES-EBU based ‘cookie cutter designed’ systems. However, asynchronous USB audio is also far from perfect.

Over time as we gain more experience with USB Audio, we find much room for improvement for asynchronous USB audio; just as sufficient experience showed that SPDIF implementations needed care.

1.3 What about alternative systems like Firewire or Ethernet?

Lest someone suggest that if SPDIF and USB are fraught with problems, we should instead use Firewire, Ethernet or some other as of now unknown protocol - all these protocols are developed as general purpose systems, not as something dedicated to audio (SPDIF was originally a ‘debug’ port using video signaling) – each are subject to their own set of problems - there is no silver bullet/panacea.


2. A Matter of Class

2.1 Audio vs. Data transfer
It must be understood that USB audio devices (and USB video streaming) have much stronger requirements for USB hardware and software layers than any other USB devices, such as printers, hard drives or flash drives.

Further, USB Audio Class 2 devices (2 Channels@32Bit/768khz) have even greater requirements due to the much higher throughput at high sample rates compared to USB Audio Class 1 devices (2 channels@24Bit/96kHz). They must run at the much higher speed even if only streaming lowly CD standard signals. The key issue is that USB Audio Class devices use ‘Isochronous’ transfers while other devices use ‘Bulk/Burst mode’ transfers.

2.2 What is Isochronous mode?

“A sequence of events is isochronous if the events occur regularly, or at equal time intervals.”
Source Wikipedia - https://en.wikipedia.org/wiki/Isochronous

Isochronous mode is used for media streaming because it guarantees bandwidth on the USB bus by scheduling one transfer per available frame. By comparison Bulk or Burst transfers make use of ‘leftover’ bandwidth and may be ‘choked off’ if higher priority isochronous data transfers saturate the USB Bus.

Isochronous transfer mode uses error-checking but includes no re-transmission in case of Cyclic Redundancy Check (CRC) errors. Electrical noise on USB signals causes CRC errors and thus data loss, as does poor signal integrity. In mild cases, this leads to audio signal distortions. In the worst cases, clicks and dropouts. It means that a USB audio device can work correctly only if USB signal quality is excellent and no CRC errors occur.

Note: Do not confuse ‘asynchronous USB’ with ‘Isochronous,’ an asynchronous USB system still uses Isochronous mode to transfer audio.

3. Of Mice and Fans (and Curley’s Wifi)

3.1 Why is my pet mouse so well-behaved?

Most other USB device types (e.g. USB mouse, USB hard drive, USB flash drive, USB printer, USB Fan and yes, Wifi Sticks) are based on bulk transfer mode, which uses automatic re-transmission in case of errors. These kind of devices are much more tolerant of USB signal distortion.

For this reason, it is possible that a USB mouse, USB keyboard, USB flash drive, USB printer etc. all work well on a given USB port and using a given cable, while an audio device does not work with the same port or cable.

3.2 Which way did USB audio go, George; which way did it go?
A partially faulty hardware component, e.g. out of spec USB cable or USB port (which is more common than one might suspect), may not have an impact on standard USB devices such as a USB flash drive but can be catastrophic for a USB audio device.

A USB Audio Class 1 Device (no driver required on Windows, 2 channels@24Bit/96kHz) may function perfectly, but a USB Audio Class 2 may not, even if using the same port or cable and a low sample rate.

3.3 Encountering unexpected Cyclic Redundancy Check (CRC) Errors
In 2014, audiophile and technologist Fred Mak (known more commonly by ‘Fmak’ moniker) showed that with some combinations of cables and USB devices, asynchronous USB audio streaming can evidence disturbingly high levels of CRC errors.

Though his observations were under-appreciated, we at AMR can concur as we found in 2010 that in some cases, active USB cables were able to cut the USB audio error rate to zero. Using cables with a tight impedance specification also helped greatly to eliminate such errors; leading ultimately to the introduction of iFi USB audio improvement devices and cables.

4. Ports, Cables, Packets and Noise

4.1 Being ‘PC’ (Port Correct)
On some PC main boards (or laptops) signal quality of some USB ports is insufficient for isochronous streaming. The cause could be that on the PCB USB signals are routed close to a switching voltage regulator, for example. Even computers by the biggest brands are not immune.

External USB ports (mounted on a front panel or elsewhere in the PC case) are a possible source of USB signal distortion. Quality of cables or connectors used to connect the external USB port with the main board could be insufficient, or internal cables are placed close to the power supply or other sources of electrical noise.

Here is what an interesting Pro Audio article said on the technical performance of different USB ports:

Native Instruments thinks that the issue is serious enough to include recommended USB ports for Mac users in all it’s (sic) soundcard manuals in the Troubleshooting section.  Hercules also have it in their FAQ.
Serato do not go into specifics as to which port to use, but acknowledge that one port is “good” and the other “bad”.

4.2 USB cables
Quite often, the USB cable (or its connectors) is the main cause for USB signal distortions. Some cables (regardless of cost) available in the market do not adhere to the correct 90 impedance and are not suited for USB 2.0 high-speed communication (480 Mbps). Also the maximum allowed cable length of 5 meters should not be exceeded.

The following eye pattern succinctly illustrates what goes is desirable/undesirable when it comes to signal integrity.

Source: http://www.edn.com/design/test-and-measurement/4389368/Eye-Diagram-Basics-Reading-and-applying-eye-diagrams

Some special USB cable offerings despite being optimised for audio, or cables which include additional functionality such as status LEDs can cause poor signal integrity. Cables for USB Audio Class 2 devices should be certified for USB 2.0 use and follow the formal USB Specifications tightly.


4.3 USB frame and packet noise
We also find factors like the noise/jitter levels induced by the packetised nature of the USB Protocol. For example, Full Speed USB (12MbpS - USB Audio Class 1, 2 Channels@96kHz), transfers one packet of data every 1 millisecond, giving rise to a 1kHz frame rate. This may manifest itself as noise at 1kHz.

For High-Speed USB (480MbpS - USB Audio Class 2, Two Channels@768khz), transfers one packet of data every 125 microsecond, giving rise to a 8kHz micro-frame rate. This may manifest itself as noise at 8kHz.

Frame noise
As stated, USB uses 1ms and 125uS signal frames, hence the creation of 1kHz and 8kHz frame noise. Below is a Stereophile test result of quite popular USB DAC from a reputable manufacturer, which clearly shows the 8kHz frame noise.

Packet noise:
Due to the nature of the USB signal packet itself, it will create a 64-104kHz packet noise.

Due to limits on the data contained within each frame additional noise components may be generated, usually at inaudible frequencies, which nevertheless can translate into jitter that will fold back into audible frequency ranges.

All of this applies before we even account for such factors as the quality (noise levels) of the USB Bus power that is used to power many less expensive USB DACs.

Therefore, both Frame and Packed noise need to be addressed.


5. Measure > Test > Develop. Circum et circum. Advancing USB audio.

Given the issues and limitations designed into USB audio it should come as no surprise that USB devices may be created that are found to improve the sound quality, even if we have yet to find a way to reliably and consistently measure their impact using standard test gear (e.g. our Audio Precision System).

At iFi/AMR we have in fact been able to use the Audio Precision System to measure such factors as USB power noise and frame noise, though it often requires new tests to be programmed and set up and to be validated, not a trivial job as putting probes here and there.

iFi is an ardent supporter of improving all aspects of USB audio, from USB power (iUSB Power - introduced in 2012) to signal integrity (Gemini and Mercury USB Cables & iPurifier - introduced in 2013).

With the latest ranges of USB audio focused improvement devices (such as the iPurifier2 and nano iUSB3.0 and micro iUSB3.0) we have updated our range to address the full range of issues known to us and to maximise the available quality from USB audio.

Computer audio certainly does not stand still, it develops dynamically and with some speed.



References
Stereophile. Bits are Bits. http://www.stereophile.com/features/396bits/#zpBshxQYxDMhwege.97
Stereophile. A Transport of Delight: CD Transport Jitter. http://www.stereophile.com/features/368/index.html#S1YySTosJVjzlvs6.99
Stereophile.The Jitter Game. http://www.stereophile.com/reference/193jitter/index.html#syTSmCg8Dvckym2F.97
EDN Network. Eye Diagram Basics: Reading and applying eye diagrams.
http://www.edn.com/design/test-and-measurement/4389368/Eye-Diagram-Basics-Reading-and-applying-eye-diagrams
Pilmat. MacBook USB Port Inequality. http://djtechtools.com/2010/07/14/macbook-usb-port-inequality/
Wikipedia. Cyclic Redundancy Check. https://en.wikipedia.org/wiki/Cyclic_redundancy_check

[skunark]

Pez,

You should describe clock recovery and how USB devices can do a poor job independent of the USB cable (and bonus points on explaining why HDMI has the same issue but based on the video rate).   There's a real advantage over asynchronous USB DACs that makes the measurable clock jitter point moot. 

Switching and clock noise for any digital circuit with analog has always been a problem, of course having a cable that meets the specifications is required, but also having the correct filtering circuitry, galvanic isolation and a separate power supplies from the digital and analog circuitry would be the first things to address.

Jim
 

[Pez]

Ask and ye shall receive!

Clock recovery in all these systems and indeed all systems using data with embedded clock relies on (D)PLL Systems and formatting data is such a way that the clock recovery system can lock onto the incoming signal. It is required to correctly decode the data.

As long as all data send is correctly recovered, it does not matter how good or bad a job a device does in clock recovery, as long as data transfers remain asynchronous and separate audio/video clocks are used non of the jitter in the data transmission is transferred to the audio/video device.

That said, poor clock recovery systems (not just in USB) can lead to data loss or corruption. And  in all systems that do not have mechanisms to retransmit lost or corrupted data there is no way to get this corrected.

Systems that transmit audio (and video) data with data integrity checks but no re-transmission if data integrity checks fail are SPDIF, HDMI, IEEE1394, & USB in isochronous streaming mode and Ethernet/Wifi in Audio/Video streaming mode.

That this permanent corruption of data can (and does) happen in these systems is generally not well recognised. And that the risk of this data corruption increases dramatically with poor cabling combined with poor system design is again underappreciated.

"Switching and clock noise for any digital circuit with analog has always been a problem, of course having a cable that meets the specifications is required, but also having the correct filtering circuitry, galvanic isolation and a separate power supplies from the digital and analog circuitry would be the first things to address."

We are now talking about minute specifics of device design, if the data the device receives cannot be correctly decoded because of upstream issues, even the most perfect design will fail.

So we must address a wide range of problems correctly in Audio Systems, be they analogue, CD-Digital with or without separate DAC or Computer based. Of course, as complexity in such systems increases, so do the opportunities for SNAFU's(1) and FUBAR's(2)...

1) SNAFU - Situation Normal All Fouled Up
2) FUBAR - Fouled Up Beyond Any Recognition

[skunark]

* Asynchronous: Source and the sink have independent free-running clocks,   The sink can have a very precise clock for the DAC, this is why we prefer Asynchronous DACs over the other two types.
* Synchronous: Source and sink lock their clock to the special 1ms indicator in the data that can step up or down the clock as required.
* Adaptive: Sink locks the clock on the data flow sent by the source.

So for PC USB audio, the last two relies on the PC oscillators for clock-recovery as it sends the data and a lot of times, the adaptive and synchronous DACs won't support all clock-rates and the driver will convert the file as required.  Not really the best method to play audio...   

As for HDMI, if you utilize one HDMI cable for video and audio, the audio has to piggyback with the video and it too can have the same issues as adaptive USB DACs with possible conversions at the source.  If you use a dedicated HDMI cable for audio, it will still be adaptive, but with the unmodified source. 


Data loss with both HDMI and USB would be noticed as audio glitches or video artifacts, which might indicate the cable isn't up to spec.   For HDMI, the data is encoded and encrypted if the data was corrupted all you can do is discard the pixel.