USB Nervosa Thread Decrapifiers, pro interfaces, and bears oh my

Thanks for the work, and pardon my unfamiliarity, but I would think that the Gustard has no audible effect on the sound, which I think is what the differential shows, as well? And if it does have a sound difference (and i don't know) then the measure doesn't reflect what actually is causing a change? Again, not trolling, as I haven't heard the Gustard in use.

 

So...not to go full nwavguy, but what else could to be measured here to get a more complete picture? Jitter? Noise/distortion?

 

Being a loopback, this isn't going through a DAC or transducer, so it's pure data, essentially still digital. I suspect most/all coloration happens in the analog segment. The data are audio samples, and are streamed, but never get converted.

 

Oh, sure... you can get lucky with 67,737,552 bits. But what about the 67,737,553rd? Ha!

I wish Terry Pratchet was still around to write about this stuff.

 

PC: Asus Ultrabook UX31E
USB Hub: Vaunix Lab Brick USB
http://vaunix.com/products/usb-hubs/overview/

USB cables are Audioquest Forest which I have tested to assure proper shield ground implementation
http://www.audioquest.com/usb-digital-audio/forest

There are plenty of USB cables that when there is any motion involved on the cable one can observe the ground impedance changing on an LSR meter. The cable I use has a solid shield connection at both ends and maintains a very low impedance even when motion / movement is induced. It is also relatively modest in cost.

Here is the exact USB port configuration:


The Mutec devices offer format conversion, galvanic isolation, decent ASIO drivers and reclocking with purportedly better clocks. However the native power supply is SMPS with all the potential issues that brings. Thus you see many supplying an external LPS to potentially reduce the system residual noise floor.

One of the reasons I find the Gustard U12 useful is it has similar features to the Mutec with exception of reclocking and one might argue inferior clocks. It does have a native LPS. No SMPS noise issues. And it is also relatively modest in cost.

 

While not the ultimate solution that other, more expensive DDCs present, it would appear that the U12 does provide DDC function with galvanic isolation and a solid ASIO driver for not much money. An inexpensive way to experiment with one's personal system, which also has much influence on the results.
Were the slight differences repeatable between data runs for the same USB-SPDIF converters? Sometimes small differences are just where the window fell on a particular FFT.

 

I've been looking into the Lynx E22. At first, I thought that I wouldn't be able to use it because I have a MacBook Pro without a PCI expansion slot...but then I found out that Sonnet and Magma make Thunderbolt-compatible chassis.

It seems to me that the Thunderbolt connection would essentially be acting as an Ethernet connection in this circumstance, but I don't know a ton about Thunderbolt. Would this be an effective use of the E22 and a good solution for avoiding USB, or would the Thunderbolt connection introduce a new set of issues into the equation?

 

I dunno. Maybe I should watch for multiples of 42 in the data series after a billion bits. But you do raise a real good point. Did this particular run just get lucky? I will try to find time to run a much longer test. I'm thinking 10 minutes ought to be good. That tests 1.3 B bits.

 

While this is a great test, I really don't think bit flipping (data errors) is often (or ever?) sited as an issue with USB audio in the literature. That is a catastrophic error which isn't required for SQ degradation. E.g., I suppose sample to sample jitter and zero latency combine to create IMD in the digital to analog conversion process. I'd actually be more interested in measurements of the analog signal at the output of the DAC each time alterations to the digital interface occur (decrapification, AES vs USB, USB from one host or another, etc).

 

Not sure if there is sarcasm here. If the probability of error in any bit is 1/100,000,000. Then the probability there is an error somewhere in the 67,737,552 bits is 0.492 which means that if you ran the test a few times (like > 2) to verify the results and got no errors, then there's no read for the longer test.
Of course, the smaller the per-bit probability of error, the longer the test should be to achieve this confidence.

 

I think you have to be a bit more pratchet-like with this. It's been a while since I read those books, but there was thing that, if you wanted to achieve the impossible, you had to manufacture a situation where the odds were exactly a-million-to-one-against --- And then you'd achieve it.

So scaling the thing up to allow for a generation of computer stuff since it was written, we should probably test a gigabyte, or even a terrabyte. If we do so, then, and only then, will we get the results that we want. Whatever that is

 

I could test billions and billions of bits n times. On a windoze system, it is guaranteed that the n+1 time when demonstrated publicly will fail.

 

Another factor that seems to be important and is directly related to the method used by USB, is the delivery/source of the timing of the data stream itself.

From what I understand USB combines the timing and the data in the same stream.
This combination, when additional sources of noise and jitter are also mixed into the USB data stream makes for additional complexity and contamination of the entire data stream being delivered to the dac.
This is supported by the use of decrapifiers in any and all combinations as has been noted by many.

Additionally what has also been observed is that by using the ethernet path these 2 essential aspects are separated and are 'handled' independently of each other.
This along with the increase in galvanic isolation being employed by ethernet (which can be improved using the FMC approach) seems to be a significant factor right along side the accuracy of the timing (re-clocking) of the data stream itself.

IOW the integrity of the data itself doesn't seem to be too much of an issue (unless the connection is so bad that dropouts and 'hiccups' are a common occurrence) which leaves all of the 'secondary' issues and factors as the main set of issues we are addressing in our attempts to 'clean up' the digital audio path from source to dac.

JJ

 

Well, I have two USB cables: Belkin Gold and Generic OEM cable with two ferrite beads on each end.

When attached to a printer, both cables printed without errors and timed the same.

However when attached to a dac, the generic cable sounded duller, with less air. Belkin Gold presented a more neutral sound.

Maybe there's something wrong with my dac or my hearing. #bits are bits.

 

There are at least three attributes to consider with the USB data delivery:
1. data integrity (bits are bits)
2. data delivery timing (jitter)
3. noise on the data delivery cable (noise floor)

My testing only proved 1) data integrity (bits are bits)
Look at each of the technical measurements I published, specifically the jitter spectrum. Noise floor may also be seen on those graphs. They do vary depending on delivery medium (USB, SPDIF, toslink, etc.) Someday it may be interesting to attempt comparing different USB cables on the same DAC.

 

As an experiment try removing the 2 ferrite beads (if you can) and listen again.

Then try cleaning the contact points in the USB connectors themselves and listen again.

My guess is you should hear differences due to both experiments.

JJ

 

Yes, they are.