• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Bit perfect audio article

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO

Cosmik

Major Contributor
Joined
Apr 24, 2016
Messages
3,075
Likes
2,180
Location
UK
Thanks for that. It makes it all sound so complicated and fraught with problems, though. I'm sure that similar articles could be written about the difficulties of charging batteries, receiving GPS signals, ethernet communications etc. i.e. if we use old chipsets we may have to contend with old problems.

Synchronous USB is obsolete for high end audio, and asynchronous USB doesn't cause "audible pops"; The "complications of buffer management" are not an issue because clever people probably thought it through before asynchronous USB was even launched, and burned their expertise into chips that cost $0.10.

This article reminds me strongly of many dealings I have had with hardware engineers over the years: they love to make stuff seem a lot harder than it really is. They also love to re-invent the wheel and 'play' with new stuff (new to them, that is). I was chatting to a hardware engineer about a power supply he had designed that met rigorous EMC conditions and was cheap to make - it had been a nightmare to design apparently. I said to him "At least you'll never have to do it again, but can just re-use this one in future". He replied "You've got to be kidding. That's not what I signed up for - I'll do it another way next time". I suspect that a lot of electronics-based industry has a hidden overhead: engineers who 'play' with stuff that managers don't understand and just go along with. The USB article above has the same feel: it worries about the pitfalls and problems of systems that are obsolete or have been solved totally by industry standard chipsets.
 

jmlpartners

Member
Joined
Jun 30, 2016
Messages
10
Likes
3
Location
North Texas

Hog wash! First and foremost, USB Audio is not bit perfect. USB Audio uses the Isochronous transfer protocol whereby the receiver does not acknowledge packets received. Without acknowledgement there cannot be retransmission of lost or garbled packets. A data transmission method that does not fix correctable errors and report uncorrectable errors is not bit perfect.

Second, USB audio does not use the Synchronous variation of the Isochronous protocol. It uses either the Adaptive or Asynchronous variations. In addition, the diagram of the Asynchronous method is incorrect because it omits the feedback loop whereby the receiver tells the transmitter to adjust the data rate to match the receiver's clock.
 

Blumlein 88

Grand Contributor
Forum Donor
Joined
Feb 23, 2016
Messages
20,523
Likes
37,056
Well I have sent test signals for hours over asynch USB recording the samples at the other end. Not one single sample was mangled. Seems if sent bits and received bits match that is bit perfect enough.
 
OP
DonH56

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO
I am no expert on USB interfaces, though have had to deal with bit-perfect transmission through digital RF systems for decades. USB always struck me as a scary way to do things due to the lack of advanced error correction and packet retransmission protocols. There is some error checking built in, but it is usually up to the driver (or OS) to determine when to raise the flag to the user for a manual resend. I found the article interesting but suspect, like many others on that site, the comments will quickly flow in to correct and update it.

As for HW engineers, there are many varieties and personalities. Pretty much every design I have done has provided some insight into how to improve the next iteration, though whether or not those insights are ever put into practice depends on a lot of other factors. Whilst I cannot deny the desire to "play" or that there are hidden costs in the lack of re-use, we must remember that from some of that "play" a lot of new inventions and revelations have been spawned that lead to great improvements in product performance, significant cost reductions, and so forth. The trick for most of us (low-brow engineers) is to balance when re-use is more desirable to meet time-to-market and cost targets vs. the design effort to develop the technology and circuits needed for new features.
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,368
Likes
234,388
Location
Seattle Area
Hog wash! First and foremost, USB Audio is not bit perfect. USB Audio uses the Isochronous transfer protocol whereby the receiver does not acknowledge packets received. Without acknowledgement there cannot be retransmission of lost or garbled packets. A data transmission method that does not fix correctable errors and report uncorrectable errors is not bit perfect.
First, welcome to the forum. :)

On your comment, what you state is a matter of reliability, not bit perfect. If you hit pause on your CD player every now and then, does that make it not bit-perfect? It doesn't. It is bit perfect but doesn't function 100% reliably.

And despite the theoretical possibility, I have yet to see documented cases of USB errors in audio applications. With short connections to a DAC, that just doesn't happen. Schemes with retransmission are harder to use for real-time applications anyway.
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,368
Likes
234,388
Location
Seattle Area
Just finished reading the article. It is a pretty nice overview of what a design engineer who doesn't know audio will be getting into in making either configuration (async vs sync) USB work. As end users we take for granted that a DAC has multiple sample rates and it must attempt to change configuration on the fly to what is coming in. That is the bulk of the article, addressing what you have to do to either create such a clock from USB clock (sync) or your own (async). It talks about how the former is simpler from buffer management but complex from clock generation. And the reverse for the async mode.

Yes, cookbook designs do exist and many DACs are based on those existing practices. While EDN also covers such, this one is a staff writer article meant to provide an overview should an engineer want to build their own.

It is a proper overview for design engineers which is the audience of this site.
 

Vincent Kars

Addicted to Fun and Learning
Technical Expert
Joined
Mar 1, 2016
Messages
781
Likes
1,555
USB always struck me as a scary way to do things due to the lack of advanced error correction and packet retransmission protocols.

It depends on the mode.
For AV they choose the isochronous transfer mode.
As this a quasi real-time stream, even if you detect errors you don’t have the time to correct because of its “real time” nature.
Pretty much like SPDIF or AES, these protocols offer the option for error detection but no retry as this is impossible (a real real time-stream)
I believe UDP does the same over the network, error detection but no retry.

There has been implementations of USB audio drivers using Bulk mode.
There you have the retry (but not guaranteed bandwidth) . It turned out a costly and bug prone affair to do so (first generation M2Tech)

Today almost everybody uses UAC1 or UAC2.
 

Vincent Kars

Addicted to Fun and Learning
Technical Expert
Joined
Mar 1, 2016
Messages
781
Likes
1,555
you have to do to either create such a clock from USB clock (sync) or your own (async).

What is missing is that there are 3 modes or better 3 ways of synchronization

Synchronous
The clock driving the DAC is directly derived from the 1 kHz frame rate.

Adaptive
The DAC runs its own clock but its speed is dependend on the incoming data stream

Asynchronous
The DAC runs a fixed clock, it control the amount of data send by the PC

Bit more detail: http://www.thewelltemperedcomputer.com/KB/USB.html

Today almost every decent DAC run Asynchronous synchronization
 

Fitzcaraldo215

Major Contributor
Joined
Mar 4, 2016
Messages
1,440
Likes
632
First, welcome to the forum. :)

On your comment, what you state is a matter of reliability, not bit perfect. If you hit pause on your CD player every now and then, does that make it not bit-perfect? It doesn't. It is bit perfect but doesn't function 100% reliably.

And despite the theoretical possibility, I have yet to see documented cases of USB errors in audio applications. With short connections to a DAC, that just doesn't happen. Schemes with retransmission are harder to use for real-time applications anyway.

I agree. Though USB bashing is a popular sport among computer audiophiles, I have also seen no measurements anywhere that support the lack of bit integrity with properly done, modern asynch USB implementations in audio. People talk a lot about theoretically this or that could happen, but it does not appear to be happening in any measurable way they can demonstrate. John Swenson, for example, is a master at raising fear, uncertainty and doubt via theory, but never providing any measurements. And, to computer audiophiles, he is a hero.

A sidelight. I recently helped a guy from Holland in a forum overcome some nasty problems he attributed to a very excellent Mch asynch USB DAC he owned: loud audible noise and channel assignment confusion. I own the same Exasound E28 DAC and I am quite happy with it. But, it had blown out his tweeters, he claimed, and he was complaining to the world. The DAC manufacturer had even sent him a brand new DAC worth $thousands. Same problems. The DAC maker was unable to duplicate the issues on the old DAC. Then, the guy finally revealed his entire system setup, and I saw the problem immediately.

It turns out he was using a passive 10-meter copper USB 2 cable, which is double the length the USB 2 spec allows. He totally eliminated the problem with a spec-compliant 5-meter cable, and he is in the process of trying a 10-meter Corning glass fiber cable. I tried that myself once, and it does work properly. The guys who sold him the metallic 10-meter cable should be shot at sunrise.

I myself use a not very expensive 5-meter metallic USB2 cable with absolutely no problems and excellent sound into a very well isolated DAC. I never had better sound.
 
OP
DonH56

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO
In my limited experience with USB DACs the problems I see most often are due to poor power and ground isolation from the PC, and very high jitter for the inexpensive units that do not buffer and reclock the data. Even the latter is much easier measured than heard, again IME.

A guy at work was gushing over his $100 USB cable and how it improved his DAC. Turns out there was a nasty ground loop and the new cable provide galvanic isolation. He was somewhat miffed when I pulled the shield line at one end of a cheapie cable and it also cured the the issue... He claimed he could still hear better <insert audiophile adjective here> after the change, but they sounded the same to me, and the same to him when I swapped cables and asked him to tell which was in line.

Sometimes there are real scientific (excuse, me "engineering") reasons for bad and good things we hear.
 

jmlpartners

Member
Joined
Jun 30, 2016
Messages
10
Likes
3
Location
North Texas
Well I have sent test signals for hours over asynch USB recording the samples at the other end. Not one single sample was mangled. Seems if sent bits and received bits match that is bit perfect enough.

Consider yourself lucky. A few hours without error does not prove perfection.
 

Cosmik

Major Contributor
Joined
Apr 24, 2016
Messages
3,075
Likes
2,180
Location
UK
At what point does an electrical connection become a 'communications link'? On a PCB, we happily connect integrated circuits together with tracks and feel no need to implement error correction or any sort of re-transmission mechanism. In some types of CNC machinery we count pulses from rotary encoders, fed via differential links, in order to know the position of things. I am reasonably happy to think of a short USB cable as not much more than such a connection. If there are going to be errors, they're going to be software and OS related, and extra error checking, re-transmission requests etc. are not going to help us.
 

jmlpartners

Member
Joined
Jun 30, 2016
Messages
10
Likes
3
Location
North Texas
And despite the theoretical possibility, I have yet to see documented cases of USB errors in audio applications. With short connections to a DAC, that just doesn't happen. Schemes with retransmission are harder to use for real-time applications anyway.

First, you don't see documented cases of USB errors in audio applications because they don't report errors. There is no mechanism in the protocol whereby the host can learn about corrupt or missing packets from the endpoint. How many audiophile DACs have a LCD counter that displays a count of packets received with CRC errors and there is no way to count the packets that were sent but not received.

Second, if the comments here are an indication, audiophiles are prone to use very long cables, often made of exotic materials and not conforming to USB specs. The rate of dropouts in audiophile installations is probably much higher than that experienced in a testing lab. Can you hear a 125 us dropout? I doubt it because you have not been trained to recognize it. I doubt most

Third, audio playback is not a real-time application. USB 2 has plenty of bandwidth for retransmission of packets in an audio data stream.
 
Last edited:

RayDunzl

Grand Contributor
Central Scrutinizer
Joined
Mar 9, 2016
Messages
13,202
Likes
16,982
Location
Riverview FL
I'm using a 25 foot Triplite cable with a repeater in the middle of it, fixed my trouble. Don't know if it created any new ones.

As soon as I see bit errors in my room measurements, maybe I'll get concerned.

On the other hand, a little DRC throws everything electrically "perfect" out the window, so...
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,368
Likes
234,388
Location
Seattle Area
First, you don't see documented cases of USB errors in audio applications because they don't report errors. There is no mechanism in the protocol whereby the host can learn about corrupt or missing packets from the endpoint. How many audiophile DACs have a LCD counter that displays a count of packets received with CRC errors and there is no way to count the packets that were sent but not received.

Second, if the comments here are an indication, audiophiles are prone to use very long cables, often made of exotic materials and not conforming to USB specs. The rate of dropouts in audiophile installations is probably much higher than that experienced in a testing lab. Can you hear a 125 us dropout? I doubt it because you have not been trained to recognize it. I doubt most
Given all of this, what is the worry about lack of error correction again? What are you losing that you hope to fix?

Third, audio playback is not a real-time application. USB 2 has plenty of bandwidth for retransmission of packets in an audio data stream.
Of course it is real-time. At every sample period you better have a piece of data to feed the DAC or it starves and you get distortion. You have no option for flow control of the DAC (silicon). It is by definition a real-time system. Fact that it runs slower than the link doesn't make it non-real-time.

As I said, adding error retransmission makes things hard. Today USB implementations are simple. If you add error retransmission, they no longer are. You would need a complicated state machine or likely a microprocessor to handle such retransmission and much more buffering to keep things around to retransmit. TCP/IP does that for networking but that requires a host processor. All else being equal, we want to keep the interface logic simple and hence quiet.

Now, if we could demonstrate that erroneous data transfers are real and frequent problem, sure, we could address them. But they are. You say that users don't have such instruments or ears but designers do. Yet they have not documented such problems either. People who are concerned can use Ethernet interface and DACs. I personally think that is a poor trade off unless you need the much longer distances Ethernet can travel.
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,368
Likes
234,388
Location
Seattle Area
A sidelight. I recently helped a guy from Holland in a forum overcome some nasty problems he attributed to a very excellent Mch asynch USB DAC he owned: loud audible noise and channel assignment confusion. I own the same Exasound E28 DAC and I am quite happy with it. But, it had blown out his tweeters, he claimed, and he was complaining to the world. The DAC manufacturer had even sent him a brand new DAC worth $thousands. Same problems. The DAC maker was unable to duplicate the issues on the old DAC. Then, the guy finally revealed his entire system setup, and I saw the problem immediately.

It turns out he was using a passive 10-meter copper USB 2 cable, which is double the length the USB 2 spec allows. He totally eliminated the problem with a spec-compliant 5-meter cable, and he is in the process of trying a 10-meter Corning glass fiber cable. I tried that myself once, and it does work properly. The guys who sold him the metallic 10-meter cable should be shot at sunrise.
I helped Lee on WBF resolve a similar issue with his new DAC. It was glitching from time to time. The DAC vendor kept sending him different mods like new clock boards and such. But to me, it seemed like a simple data starvation. I asked him what player he was using and it was one of those "audiophile" players on MAC. Had him run performance monitor and its CPU was maxing out. Problem was the visualizations (fancy graphics) to the player. It was sucking all the CPU cycles causing buffer underruns. Once the DAC runs out of data to play per my last post, bad things happen.

He turned off the visualization and everything was fixed. He reported the problem and the player company fixed it in their next release.
 

RayDunzl

Grand Contributor
Central Scrutinizer
Joined
Mar 9, 2016
Messages
13,202
Likes
16,982
Location
Riverview FL
People who are concerned can use Ethernet interface and DACs.

I vote for Self-Healing Bidirectional SONET rings in the Home... for those who are concerned...

I did Bit Error Rate tests on cross-country and undersea DWDM fiber systems.

Just playing in the lab, the error correction was so robust you had to have a totally unreasonable amount of transport fail before an error would ever show up at the endpoints.
 
Top Bottom