First, welcome to the forum.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.
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.
If you hit pause on your CD player every now and then, does that make it not bit-perfect?
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.
Given all of this, what is the worry about lack of error correction again? What are you losing that you hope to fix?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
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.Third, audio playback is not a real-time application. USB 2 has plenty of bandwidth for retransmission of packets in an audio data stream.
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.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.
People who are concerned can use Ethernet interface and DACs.