MEASUREMENTS: [UPDATE] Adaptive AUNE X1, Asynchronous "Breeze Audio" CM6631A USB, and Jitter...

In late February, I received an interesting USB2 --> SPDIF box from Asia. It's based on the C-Media CM6631A chipset (it says "Breeze Audio" on the metal case and "CM6631-V1.4" on the PCB) which communicates with an asynchronous USB2 protocol (recall that the Asus Essence One uses the CM6631).

Total price ~$50USD shipped.

Although it's said to be plug-and-play compatible with Mac OS X, I've run into a few snags which I won't discuss here - just be aware if you're planning to use this on the Mac (SEE ADDENDUM - ISSUE FIXED!)...  However, I'll restrict these measurements to the Windows 8 environment only where the custom drivers work well.

The idea I wanted to explore was whether using an asynchronous converter like this connected to the AUNE X1 would be better in terms of jitter than the adaptive USB port of the X1 itself. Also, how sensitive is jitter to computer load?

Note that beyond jitter, there are some other obvious reasons to do this... Firstly, using the CM6631A box allows hi-res TosLink/coaxial output up to 24/192 if you don't have a USB2 DAC. Secondly, it might be better to keep peripherals all running at high speed if you're going to be plugging this into a USB2 hub.

Lets take a look at the adaptive USB jitter spectrum directly from the AUNE X1 (remember, only up to 16 bits, so I'll be using the 16/44 Dunn J-Test signal) [UPDATED April 1, 2013 - SEE BELOW]:
(Setup: i7 computer --> shielded USB --> AUNE X1 --> shielded RCA --> E-MU 0404USB)

Numerous sidebands with spurious noise. I guess this is pretty typical of a very pedestrian adaptive USB1 interface. It doesn't "look" good but for the most part, these spikes are down below 100dB from the 11kHz primary tone.

Not only is adaptive USB said to be bad for jitter, but some believe it's especially prone to timing errors if you're multitasking...  Lets see what happens when the CPU is under 100% load (Prime 95, 8 threads), and to make it worse, lets also run the GPU (nVidia GTX 570) 100% with FurMark:

Essentially no difference to the spectrum whether the computer is fully loaded or not! You see a bit of noise showing up between 8-9kHz but it's all very low amplitude (again >100dB below the 11kHz peak).

Let's now put the CM6631A asynchronous USB --> SPDIF in the chain. Here's the setup now starting with a proper coaxial SPDIF 'digital' cable (Acoustic Research brand):
i7 computer --> shielded USB --> CM6631A --> shielded digital coaxial --> AUNE X1 --> shielded RCA --> E-MU 0404USB

This is a very nice 16/44 J-Test graph with minimal data correlated sidebands and most of the peaks are just due to the 16-bit J-Test modulation tone.

What happens with the CPU and GPU running at 100%?

No difference!

What about we use the TosLink output from the CM6631A instead?
(Setup: i7 computer --> shielded USB --> CM6631A --> decent plastic TosLink --> AUNE X1 --> shielded RCA --> E-MU 0404USB)

In this setup, the TosLink interface is almost exactly the same as coaxial (I'm actually impressed by this since TosLink often tends to be significantly worse than coaxial).

What about CPU & GPU running full tilt at 100% using TosLink?

Again - no difference! (Ignore that FurMark banner... Just got in the way of the screen capture.)

OK. We've also heard that a poor coaxial cable could be bad for jitter...  That is, if there is severe impedance mismatch between connectors (supposed to be 75ohms), the theory goes that there could be reflections which could damage the digital signal transitions. Furthermore, it is said that a short 3' cable is worse than a longer cable due to the transition time for these reflections.

What then would jitter look like if I replaced a proper shielded coaxial with cheap "freebie" 3' RCA connector that came with an old Pioneer DVD player (I used the red connector)?

Eh? That's all? Really no different than with the "proper" coaxial cable!

How about with CPU and GPU running 100% using the cheap RCA cable?

Again, that's all!?

Realize that in the analogue domain, I can measurably prove that the cheapo RCA is worse than the shielded proper coaxial digital cable based on noise floor differences. But in terms of jitter (digital phenomenon) which we're stimulating here with the Dunn J-Test, in this "real world" setup, I cannot show any significant difference despite the likely poor impedance match and 3' length! (Note that I'm not saying a cheap RCA cable is as good as proper coaxial in general, just that in this inexpensive setup, it works fine... I have measured in other situations like with my ASUS Essence One paired up to a Squeezebox Touch where a cheap RCA cable actually resulted in very severe jitter issues.)

Summary:

1. The asynchronous USB2 interface works to lower jitter! Having said this, I think we have to also recognize that apart from some noise spikes, the actual jitter sidebands with the adaptive USB interface wasn't terrible and likely not audible given how low in amplitude they were.

2. Whether the computer was running full-tilt at 100% or not, I could not demonstrate any change in the jitter characteristic! This applied to adaptive USB as well as asynchronous USB --> SPDIF. IMO, this makes me question the belief in "software-induced" jitter. I suppose if your computer is totally bogged down such that the audio buffer cannot be filled on time, you'll hear severe audio degradation. However, some people believe even light multitasking worsens sound quality, or the importance of shutting down background OS processes or running "stripped down" OS'es. By extension, some people swear by various playback programs having an effect on the audio quality (ie. Decibel vs. Amarra vs. JPlay vs. Audirvana vs. iTunes vs. foobar...) even if all that's promised is "bit perfect" output. It almost always comes back to "jitter" as the explanation some how. Really? Is there any objective proof for such beliefs or even a testable hypothesis?

As I have hinted in previous posts, even though I (obviously!) believe that jitter exists and is measurable, I do not believe it is audible with music unless extreme like maybe >10ns. It's also worth remembering that research into the threshold of jitter audibility decreases with higher frequencies; but this also correlates with human hearing losing sensitivity the higher up we go - especially as we get older (therefore, sensitivity to jitter should decrease with age). These days, well engineered "high fidelity" gear should not be even close to showing 10ns jitter. Likewise, software player programs should be capable of "bit-perfect" output without difficulty or cause timing errors.

Over the years, I have also tried many software players like Amarra, Decibel, JPlay, etc... Ultimately I've never been convinced of significant differences in sound between them (so long as EQ and plugins not active). Foobar + ASIO driver sounds great to me on the PC side and I use Decibel for the Mac simply because it's inexpensive and works well to switch sampling rates.

Bottom Line: Don't worry about jitter! It's more than likely inaudible in a modern computer system and with decent (not necessarily expensive) audio gear. I see no evidence that high CPU/GPU load makes any difference to jitter. Isolating your DAC from electrical noise polluting the analogue output seems much more important.

ADDEDDUM (April 1, 2013):

I found out why there was the 15kHz peak in the adaptive USB1 tests with the AUNE X1. Had to do with some old ASIO4All drivers I had installed on the i7 computer...  A good reminder of how easy it can be to mess up settings when using a PC for audio playback!

Anyhow, for completeness, here are some updated graphs of the X1 using adaptive USB measured off my Win8 AMD Phenom X4 laptop. Note that even though the graphs look different, the conclusions are the same - asynchronous USB2 is less jittery, and when the computer is at high load, the noise floor worsens for the adaptive USB case only.

Adaptive USB1, AUNE X1 using WASAPI for 16/44 J-Test:

Now with 4 threads running Prime95:

Notice that slight noise floor elevation from 8-9kHz. Not as extreme as my i7 testbed with the powerful GPU running.

Asynchronous CM6631A --> shielded coaxial --> AUNE X1, WASAPI, 16/44 J-Test:

Nice and clean...  Looks just like with the i7 testbed. What happens with Prime95 running?

No change.

Asynchronous CM6631A --> TosLink --> AUNE X1, WASAPI, 16/44 J-Test:

Now again with Prim95 running on all 4 cores:

No difference...

OK. So I have now shown that the jitter results with the CM6631A device is reproducible on 2 platforms (i7 & AMD Phenom X4) as being low for both coaxial and TosLink. Also, the CM6631A device seems quite immune to noise from the main computer (compared to the adaptive USB interface). Both ASIO and WASAPI work well for the CM6641A. Still no evidence that the jitter pattern itself changes with increased CPU load.

ADDENDUM (March 31, 2013):

Noticed this very useful post on diyaudio.com from 'bvs':

I've recently found a solution for issue that caused when CM6631A module is connected to any Mac USB 2.0 ports. When you connect module to Mac it is detected as USB Audio Class 1.0 device and you have no ability to use anything more than 48/16. Module has a reset chip LM810M3-2.93 (http://www.nscrus.ru/content/catalog/pdf/LM810.pdf), but as we can see from the CM6631/32 datasheet, the CM6631A has a power-on self-reset. So, reset chip has been removed from a board and now the module is always correctly detected as USB Audio Class 2.0 device on any Mac USB port. This method has been tested on MacBook Pro, Mac Mini and this CM6631A module: New CM6631 USB Module Assembled Board for DAC3 AD1955 DAC7 WM8741 by Weiliang | eBay LM810M3-2.93 is a 3-pin chip located on the top of CM6631A.
So, with a needle-nosed plier, I went to work on removing that little 3-pin chip (labelled "SA B" on the board)...  Here's the result (chip removed): The unit works as expected on my MacBook Pro's now with full playback up to 24/192, no need for an external power supply, and no need for custom drivers. Remember, this modification is for the CM6631A only. Earth to Microsoft - isn't it about time we got native UAC2 driver support in the OS!? Especially considering that it's been available for OS X and Linux since 2010!