USB audio transmission isn’t bit true

[Superdad]

1 hour ago, crenca said:

What is the rate of these errors, in typical use case scenarios (i.e. computer to DAC, streamer to DAC, and shorter cables of 3 feet or less)?  The answer is "very rare" as you say but how is that quantified?

 

Using a USB protocol analyzer.  John and I each have one from Teledyne Lecroy.

 

Of course this whole conversation of bit errors has little to do with transmitted USB signal integrity--and its effect on the PHY of a DAC's USB input (ground-plane noise/bounce and packet-data noise), which ultimately affects the DAC's master clock and is the real reason why  people hear differences with USB cables and regenerators.  

[Superdad]

3 hours ago, crenca said:

Is the physical layer (the "analog" foundation of any "digital" signal for folks who don't know) noise to which you refer here, measurable?

 

Sure, and some of can be seen in an eye pattern--see very first post of this thread for example:

 

3 hours ago, crenca said:

Is the effect that this noise has on the master DAC's clock correlated in measurements if not directly measured?  If so, what tool do you use for this job?

 

John (Swenson) has measured differences in ground-plane noise right next to the DAC master clock input pin.  High-speed scope, spectrum analyzer, differential probes are the typical tools.

[Superdad]

3 hours ago, Daccord said:

Either that or the USB cable shielding contains olestra.

 

No, olestra causes one to loose their sh*ts, not their bits.  

[Superdad]

4 hours ago, esldude said:

https://www.corning.com/optical-cables-by-corning/worldwide/en/products/thunderbolt-optical-cables.html

A bit pricy, but there it is. 

 

Dennis, while you were above suggesting the Corning cable in response to someone looking for Thunderbolt galvanic isolation, the Corning optical cables include copper wires and do not provide any galvanic isolation.

Same goes for the Corning optical USB cable.

[Superdad]

13 minutes ago, kumakuma said:

For the benefit of those of us from other parts of the world, what is the difference between cranky old K1W1s and cranky old Aussies like yourself?

 

Wallabies versus kangaroos of course.  

[Superdad]

30 minutes ago, beerandmusic said:

But i don't entirely agree with the statement...., i agree with IFI that single bit errors can also cause distortion...and also don't think all dacs will drop the entire packet for a single bit error....more likely, if a packet is dropped you would hear a click/skip/dropout...but I also believe some DACS will interpolate and some will process even with errors...and clearly if it's just a single bit you likely would not even hear it....think many thousands of bits per second...you would not hear one bit...now if you have many crc errors and the dac doesn't drop the entire packet, you would have distortion....

 

B&M, this is your last warning: I am going to call the ellipsis police on you ...

I bet you might even receive more thoughtful responses if you would learn to capitalize a sentence, use a period, and start new paragraphs.  Everyone's mind is a messy place, please don't pour your stream of consciousness into ours.

[Superdad]

5 hours ago, mansr said:

Only bulk and isochronous are at all suitable.

 

Yep, and pretty much every DAC firm who tried putting out products using bulk mode eventually gave up and went to isochronous.  Just too much hassle to produce and maintain custom drivers for every OS.  The advantages to bulk mode simply are not that great.

[Superdad]

16 hours ago, beerandmusic said:

audio engineering cannot be that difficult...

 

Wow. Just wow. 

[Superdad]

12 hours ago, Audiophile Neuroscience said:

Which is more fundamentally right for audio, USB or Ethernet ( copper or optical).

Which is harder to implement to make it more fundamentally right ?

 

Neither.  Ultimately it is all getting converted to the same thing in the DAC: I2S (or (DSD).

So the DAC input stages can be: USB>I2S, Ethernet>I2S, S/PDIF>I2S.

 

There are many variables in implementation as well as challenges. Decoding, clocking, power, and isolation can be done in a myriad of ways.

 

The reasons for ubiquity of USB has little to do with hardware and everything to do with software. Computer operating systems are happy to look at USB ports and send audio to them via OS support of the UAC2 audio standard.  But operating systems do not "see" Ethernet attached DACs as "sound cards" and thus other protocols have to get involved. That's where major market fragmentation came in and we end up with choices of DLNA/UPnP, Roon RAAT, Squeezelite, AirPlay, AES67/Ravenna, Signalyst NAA, etc.

 

Any one (or more) of the aforementioned "endpoint" protocols as well as the Ethernet transmission and MAC stack itself can be implemented into microprocessors/microcontrollers (or even FPGA/ASIC if one really wanted to start from scratch and had deep pockets--into the millions). If done well (again, clocking, power networks, isolation, etc.) there is no reason that the results (measured electrical and perceived SQ) can't equal that of USB or S/PDIF.

 

But again, one can not count out software factors--the how to have your Ethernet-input DAC "seen" as a "virtual sound card." Hence the paucity--and implementation disparity--of and between DACs with Ethernet inputs.  Below are photos of some various available pre-designed board modules that are in use by a small range of DAC manufacturers. This obviously does not include those manufacturers who "roll their own" Ethernet input solutions, which is quite doable since lots of popular small chips (including XMOS, PIC32, Atmel, etc.) already include Ethernet MAC processing cores.

 

Mconnect from Conversdigital: DLNA & Roon. Used by Ayre, PS Audio, and others.

 .

e-RED-MOD from Engineered.ch Electronics: DLNA/UPnP only.

ZMAN OEM from Merging Technologies: AES67/Ravenna only.

 

Don't let the size of these boards or the sight of several seemingly large chips scare you! In each case, aside from the main processor--which is loaded with the protocols and intellectual property code of the designers--most all the rest of what you see is flash memory to load those processors with code each time power is applied. Plus a few voltage regulators and maybe a basic clock.

 

 

[Superdad]

19 minutes ago, SJK said:

There has to be a country song about that, there just has to be......

 

There ought to be, but then again I don't know a lot of audiophiles who listen to much country music. 

[Where are you Garth?!]

[Superdad]

9 minutes ago, OAudio said:

Although the USB cable is shielded, there is also generally a GND loop between the PC and DAC via mains safety earth connections. The PC switching supply noise and ground leakage currents can pollute the safety earth and appear at the USB receiver circuit in the DAC (even though there "should" be a good ground reference established by the USB lead's shield).

Indeed.

 

9 minutes ago, OAudio said:

Final area I think is very important is transmission timing both phase noise and clock speed. The differential noise above may or may not be enough to cause data errors due to eye detection errors. Even if errors are not being caused by detection errors, the differential power noise in the transmitter's & receiver's supplies will cause threshold detection jitter in the USB data stream and this does matter to sound quality (although I would agree this is not data error). I mentioned in my earlier post above I have developed the ability to accurately set the relative frequency of the individual USB clock domains governing the transmitter and receiver. I have been working on this stuff for many years, and know that as little as an 0.000005% difference in the speed of the USB transmitter and receives clock domains can be heard. USB timing really matters if you are aiming for truly high end sound quality.

So nice to read people who get this!

 

9 minutes ago, OAudio said:

I just can't say beyond doubt that the above issues cause actual errors but I have come across lots of evidence that the areas above really matter for quality. 

 

With all due respect--and a warm welcome to the Audiophile Style forum--the issues you discuss above are being addressed by some. UpTone pioneered (back in 2014) USB signal integrity improvement for audio (using a hub chip, improved clocking, and attention to PS and impedance) with our original USB REGEN. And then we leap-frogged ourselves--and those who had followed us--with the more advanced ISO REGEN in 2017. Galvanic isolation, ultra-low-phase-noise clocking, and a pile of LT3042 regulators. Measurable improvements in SI:

 

Without ISO REGEN:

 

With ISO REGEN:

 

We also put forth a couple of papers on the subjects:

https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone_REGEN_tech_summary.pdf (regarding the original USB REGEN)

and https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone-J.Swenson_EtherREGEN_white_paper.pdf?v=1583429386 (related primarily to our EtherREGEN switch but also applicable with regards to the effects of clock threshold jitter with USB as well).

 

One question for you:

Are you affiliated with a company in audio? You took the member name OAudio, write knowledgeably, and are doing PCB layout, hence my wondering.

 

Cheers,

--Alex C.

[Superdad]

22 minutes ago, beerandmusic said:

Can you clarify. 

1.  Does the Holo re-clock in the manner which you suggest above?

2. Does the holo provide it's own 5v or does it use the usb 5v? 

 

Please see my long-ish reply here:

 

Honestly, I think the discussion of DAC clocking (and feeding back of master clock across digital isolation moat to USB board--what Barrows is taking about) is only going to confuse you and is not terribly relevant to your search for a DAC. Understanding this stuff is hard enough for those non-engineers (like myself) who are steeped in it (I consider myself lucky to be very "engineer-adjacent" via my close relation with John Swenson). I think it is going to be difficult for you to choose based on informal discussion of many technical factors. 

[Superdad]

7 hours ago, mocenigo said:

The Soekris DAC1541 User Manual states "The dac1541 R-2R DAC circuit is fully isolated from the noisy computer USB interface and the SPDIF inputs are also all transformer isolated" (the also implying that the isolation of the USB init is also via transformer) and in fact on the board there are three little SMD PCB DA101MC transformers.

 

That is not correct. The Murata transformers used in the Soekris DACs are for the three S/PDIF inputs (AES, BNC, RCA).  There appear to be standard digital isolator chips on the I2S (and clock in/out) lines after the XMOS processor.  And then some VERY long traces after those--past the power supply networks--to input portion of the DAC proper.

[Superdad]

4 hours ago, asdf1000 said:

I remember early on , you said you had a Zman board in hand to evaluated

 

Without talking about any specific Uptone product, is the Zman board something you think you will use in the next year or 2?

 

Or you've lost interest in this particular board for the short term? Driver issues?

 

We have a signed developer NDA with Merging and we receive documents, updates, and pricing on their ZMAN OEM program, but we never ordered the dev boards as the project we had in mind for it is on hold.

 

I continue to maintain that acceptance and broad implementation of Ethernet (or other interface) as a DAC input standard is dependent upon freely available (if not free), well supported, multi-platform “virtual sound card” software and network discovery protocols, preferably integrated into application solutions people want to use.

 

Using the above criteria, one can understand why the long available DLNA/UPnP rarely gets much love, while the rather similar but tight integrated Roon RAAT protocol has emerged as the driving force behind recent-year’s popularity of Ethernet-input DACs and streamers.

 

I believe that the ZMAN module now includes code to support RAAT and be seen as a Roon-Ready endpoint. But for some reason ZMAN does not seem to have caught on with many consumer DAC manufacturers yet. Not sure why that is. Perhaps price. It is a much more advanced Ethernet>I2S solution than the popular Conversdigital MConnect, but a fair bit more complex to implement. Maybe that is why.

 

For greater context, see my post here: