Bit perfect audio article

[Fitzcaraldo215]

I have no doubt that audiophiles would "feel" better knowing there was some positive error detection/retransmission/correction in the digital links in their computer audio systems. That USB normally does not do that is a continuing source of agita in some circles. But, we seem to agree that there is no measurable problem that anyone, anywhere has been able to provide. Without such evidence, I conclude it is a psychological problem, a scapegoat issue for other problems elsewhere or for less than ideal engineering in their own specific PC to DAC environment via USB. That, or possibly USB is just the convenient focus of unjustified concern because recordings and/or their playback systems do not deliver sound which is "up to their expectations".

For me the acid test was when I used to watch BD videos from a hard drive connected to an Oppo player via USB2. Several friends and I shared our experiences using similar setups with careful comparisons. None of us ever saw or heard one iota of visual or sonic difference between that setup and direct playback of the silver disc from the same player. We never saw pixels twittering, color or brightness imbalances, dropouts, stuttering, pixelation, artifacts, poorer sonics, etc. This is, BTW, real time playback, just as audio-only is.

Ok, audio is not video, and the video + audio protocol is synchronous based on the video clock, not asynchronous, like audio only. But, the bandwidth and huge volumes of additional data transfer for video strike me as a major performance challenge, which is easily vanquished by USB2. How can it be claimed that computer audio, with less data transmitted and at lower bandwidth, via the same transmission link somehow has a data integrity problem via USB?

Until someone can provide hard evidence that USB2 cannot do the job, I am completely happy with it.

 

[Blumlein 88]

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

Yes, actually for those few hours it does prove exactly and precisely and conclusively that. I have done such a several hour run multiple times and not had one hickup any of those times. It is not lucky, it is a typical result. Despite the ways asynch USB theoretically could go wrong it is very reliable and robust in actual practice.

 

[Blumlein 88]

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.

Yes, you can easily hear 125 useconds of silence injected into the signal. Sounds a bit like a tick on an LP. I don't know how common it is in normal use other than if it occurs once in something less often than several hours I am not worried about it. I have indeed seen people with damaged cables or trying to use too long a cable get dropouts and other problems. Getting the proper cable or shortening the run fixed that.

I have one setup where I use one of the stupid cheap Monoprice active USB extenders for a 15 meter run (near 50 feet). No problems with it and I have subjected it to the test of running signals for several hours and confirming no issues no missing or mangled samples. So whatever someone's complaint about USB 2 audio is it isn't about messing up the bits. The bits gets transferred just fine. You are trying to trump up a problem where none exists.

 

[fas42]

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.

That's a bit disturbing to read ... looking around, I see

Considerable error checking and error handling features have been built in to the USB to ensure that it is a reliable method of connecting peripherals to a PC. Data integrity should be comparable to that of an internal expansion bus.

Immunity from data corruption by noise and spikes has been provided by the use of differential logic drivers and shielded cabling. When errors do occur, cyclic redundancy checks (CRCs) performed separately on both the control and data fields of packets will enable 100 per cent recovery of both single and double bit errors. Unrecoverable errors can be detected with a high degree of confidence.

A self-recovery mechanism is built into the messaging protocol, with time-outs for lost and invalid packets. Some error recovery is built into the hardware. The host controller will retry a failed transaction three times before reporting an error to the client software. How a reported error is dealt with is the responsibility of the client software.

at http://www.tech-pro.net/intro_usb.html. In real terms, what's the likelihood of data corruption, say using a USB hard drive to backup?

 

[DonH56]

It depends upon the protocol. I should have clarified "for audio interfaces" but really I should have stopped at "I'm no expert on USB interfaces". My current work is focused on SAS/SATA and some PCIe links and those have extensive error correction and handshaking mechanisms at the protocol level. That is what your USB drive is using (almost certainly SATA). My previous work focused on radar/lidar/sonar systems and various communication systems where high reliability was mandatory. In space etc...

 

[Fitzcaraldo215]

That's a bit disturbing to read ... looking around, I see


at http://www.tech-pro.net/intro_usb.html. In real terms, what's the likelihood of data corruption, say using a USB hard drive to backup?

I have done plenty of copies using USB 3. I never had a data corruption problem I am aware of.

 

[jmlpartners]

Given all of this, what is the worry about lack of error correction again? What are you losing that you hope to fix?

I'm not losing anything. Just saying, you can't call USB Audio bit perfect because it isn't. I don't care if you can hear the dropouts or not. They can and do happen.

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.

What rock have you been living under for the past 30 years? All the USB retry stuff happens in the USB silicon. The application never sees it and doesn't get involved. It can't. It's not fast enough. Do you really think a micro processor can keep up, at the packet level, with a 480 Mb/s, USB2 bus? How about 5 Gb/s, USB3 bus?

 

[Cosmik]

What rock have you been living under for the past 30 years? All the USB retry stuff happens in the USB silicon. The application never sees it and doesn't get involved. It can't. It's not fast enough. Do you really think a micro processor can keep up, at the packet level, with a 480 Mb/s, USB2 bus? How about 5 Gb/s, USB3 bus?

So... if there is a retry mechanism built into the silicon, what are you worried about? Why does the application need to know about it?

 

[jmlpartners]

I have done plenty of copies using USB 3. I never had a data corruption problem I am aware of.

Although you were using a USB3 cable in a USB3 port I doubt you were running at USB3 speeds. It's called backward compatibility. USB Audio does not support USB3 at the present time.

 

[jmlpartners]

So... if there is a retry mechanism built into the silicon, what are you worried about? Why does the application need to know about it?

I'm not worried about anything. Haven't you been paying attention? USB Audio transmission protocol DOES NOT use retry. That's why it cannot be called bit perfect. The decision to disable automatic retry was made in the early days of USB1 because there was insufficient bandwidth to make it worthwhile. I argue that with USB2 there is sufficient bandwidth to make good use of retry. USB bulk transfer is twice as fast as isochroous and todays micros have more than enough speed and memory provide additional buffering, as required. And since when is providing a dedicated USB port a show-stopper for a true audiophile?

If you don't hear the occasional drop out, be happy with USB Audio, as it is. I have heard them and it annoys me because with proper design they can be eliminated. That's all I have to say on this subject.

 

[Fitzcaraldo215]

I'm not losing anything. Just saying, you can't call USB Audio bit perfect because it isn't. I don't care if you can hear the dropouts or not. They can and do happen.

As I said before, I will believe that when there is measured evidence to support it. If you had any, I would presume you would have provided it by now.

 

[Fitzcaraldo215]

If you don't hear the occasional drop out, be happy with USB Audio, as it is. I have heard them and it annoys me because with proper design they can be eliminated. That's all I have to say on this subject.

Sorry, I have not heard any dropouts. What could possibly be wrong with my ears? Or, what could possibly be wrong with your system setup that has caused your current crusade?

 

[Blumlein 88]

I'm not worried about anything. Haven't you been paying attention? USB Audio transmission protocol DOES NOT use retry. That's why it cannot be called bit perfect. The decision to disable automatic retry was made in the early days of USB1 because there was insufficient bandwidth to make it worthwhile. I argue that with USB2 there is sufficient bandwidth to make good use of retry. USB bulk transfer is twice as fast as isochroous and todays micros have more than enough speed and memory provide additional buffering, as required. And since when is providing a dedicated USB port a show-stopper for a true audiophile?

If you don't hear the occasional drop out, be happy with USB Audio, as it is. I have heard them and it annoys me because with proper design they can be eliminated. That's all I have to say on this subject.

There is no need for any other design. USB audio is not a problem. If you are having regular dropouts or even occasional dropouts there is an issue with your setup. What playback software do you use, what are the parameters of your playback computer, what is the USB cable, and what is the DAC? Dropouts are coming from some of that. I have used 3 different setups and don't have dropouts. I know other people with seriously good systems who all use USB audio as digital music sources and they don't have dropouts. All USB audio must do to be bit perfect is transfer unchanged bits across the interface. That it can do. If yours does not manage it then you simply need to remedy a problem rather than spread FUD about USB in general.

 

[Cosmik]

I'm not worried about anything. Haven't you been paying attention? USB Audio transmission protocol DOES NOT use retry. That's why it cannot be called bit perfect. The decision to disable automatic retry was made in the early days of USB1 because there was insufficient bandwidth to make it worthwhile. I argue that with USB2 there is sufficient bandwidth to make good use of retry. USB bulk transfer is twice as fast as isochroous and todays micros have more than enough speed and memory provide additional buffering, as required. And since when is providing a dedicated USB port a show-stopper for a true audiophile?

If you don't hear the occasional drop out, be happy with USB Audio, as it is. I have heard them and it annoys me because with proper design they can be eliminated. That's all I have to say on this subject.

I see. If there are errors, what do you think causes them?

 

[fas42]

The playback setup I have now is amusingly pointing out that loss of audio data is really of a low, low order of importance if SQ is what one is about. Using an old, well used NAD CDP, which was always notorious around the traps for having troubles with non-standard media - I have plenty of burned CDs, and this machine has a nightmare trying to play them - the same CD in the toy mechanism of the laptop plays back perfectly. Anyway, it's hilarious listening to such a CD track being played on the NAD - spluttering, popping, scratching noises - it's like a combination of the worst 78 noises, combined with time stuttering of the replay.

The digital correction circuitry has lost the battle - but grim faced keeps going ... and, the replay of the musical event is still pretty reasonable! The qualities of the treble, space in the acoustic are still together, clearly in place - you can hear the inherent quality of the recording, very easily - it's just a bit disjointed in coming across !!

So, worrying about the last microscopic ounce of digital perfection is a complete non-issue - for me ...

 

[amirm]

I'm not losing anything. Just saying, you can't call USB Audio bit perfect because it isn't. I don't care if you can hear the dropouts or not. They can and do happen

You continue to improperly use these technical terms. The term "bit-perfect" was invented because the Windows audio stack resampled/mixed/applied gain to audio samples. Removal of these and allowing the bits to get to the driver is called bit-perfect. That operation needs not be reliable to be called that, or not. Reliability is a different vector than functionality. Bit perfect is state of functionality.

You can't bastardize the term and then keep insisting it is correct. It is not. Your argument needs to say that there is reliability problem and proceed to show that. Not have some talking point about it not being "bit perfect." If you lose a packet on a network connection, you think anyone would say "it is not bit perfect?" I think not.

 

[amirm]

What rock have you been living under for the past 30 years? All the USB retry stuff happens in the USB silicon. The application never sees it and doesn't get involved. It can't. It's not fast enough. Do you really think a micro processor can keep up, at the packet level, with a 480 Mb/s, USB2 bus? How about 5 Gb/s, USB3 bus?

Did you just jump from audio to some other application with those higher speeds???

That aside, 480 mbit/sec is half the speed of gigabit Ethernet and CPUs are able to saturate that. Here is the first hit on such speed from a Tom's hardware benchmark in 2009: http://www.tomshardware.com/reviews/gigabit-ethernet-bandwidth,2321-7.html

Those are megabyte numbers. 125 x 8 is a gigabit and achieved rate then is 900 mbit/sec. So no, 480 mbit/sec is not a problem. What rock have you been under?

That said, there was no reason to run off on this tangent as I said a state-machine can also be used.

Today, people chase interfaces like I2S that are much simpler than USB. I am confident if USB audio had error retries and such, folks would run away from it saying it is too complicated.

Fact is that USB is superior to traditional interfaces like S/PDIF and AES/EBU because it can run in async mode which rights a poor architectural decision. The DAC clock should have always been the master rather than the slave. With asynch USB, it is. Superb measured performance is achieved now and there is no hint of reliability issues you are concerned about. Async USB works. It simply does.

 

[Blumlein 88]

Repeated for emphasis:

"Fact is that USB is superior to traditional interfaces like S/PDIF and AES/EBU because it can run in async mode which rights a poor architectural decision. The DAC clock should have always been the master rather than the slave. With asynch USB, it is. Superb measured performance is achieved now and there is no hint of reliability issues you are concerned about. Async USB works. It simply does."

 

[FrantzM]

Repeated for emphasis:

"Fact is that USB is superior to traditional interfaces like S/PDIF and AES/EBU because it can run in async mode which rights a poor architectural decision. The DAC clock should have always been the master rather than the slave. With asynch USB, it is. Superb measured performance is achieved now and there is no hint of reliability issues you are concerned about. Async USB works. It simply does."

What Blum repeated for added emphasis , as this needed to be done

Audio is a low-bit application in this world where 10 GB Ethernet is commonplace. We need to keep this in mind. I am seeing Ethernet Interfaces making in-road in Audio (Pro Audio anyway with Ravenna and Dante) I like the idea. Would like to see more Ethernet DACs in our rank, much easier to interface. An Ethernet switch to drop on the network and send the signal anywhere you want with no fuss... Sound becomes even better (or the bits more perfect ) if you use one of these Audioquest cables and if you have to ask for the price ...

 

[Thomas Savage]

Diamond... If you take it down 100 fathoms it will sound even better