Did We Overhype USB Audio And Overlook Possible Pitfalls?

[crenca]

I am surmising here as I have "always" used USB, but based on my experience as a systems administrator all those years: USB suffers in that it is a general (indeed, "universal") bus designed and primarily used by the wider computer world. This means that in the commoditized computer world, the drive to the cheapest parts and implementation is very very strong. So, unless a DAC manufacture is using boutique parts/implementation he is using a USB solution that is "cheap".

 

I see no technical (or "physical law") USB can't get bits to the front side of your DAC in the same bit for bit way that Ethernet or any other bit delivery system can - even granting that it might have inherent limitations in technical design that these others don't (though I don't buy that these need apply to narrow bandwidth audio).

 

That said, your question is to the REALITY of current USB, and even then I would say that it is not "overhyped" in that on the high end boutique solutions are just a given (including avoiding USB altogether) and for the rest of the 99%, well USB is simply the "universal" bus, and as such it is what will be used (and should).

[crenca]

 

Good, we agree on this as well. I only raised the error correction issue because a previous comment implied that USB audio has error correction.

 

So, yes USB is not a packet based delivery as normally defined (as for example Ethernet {part of the TCP/IP stack}) but it is known that actual transmission errors (barring a particularly bad implementation) are statistically not significant, what IS the basis of criticism for USB in audio exactly? I have to come back to implementation effecting other things and the quality of parts/design in said implementations effecting the DACs sound in ways not generally clearly defined. What am I missing?

[crenca]

USB uses packets

 

In the context of this conversation most folks are thinking of a system like TCP/IP that will re-transmit packets if corrupted, the idea being that USB is effecting sound quality because it does not...

[crenca]

It seems to only be available on lower-cost systems. It is only with the audiophool-pricepoint that you can obtain equipment revealing enough to benefit from tinkering with paranormal phenomena.

 

 

You know, normally we don't let the secret out...

 

[crenca]

 

The error rate on a USB bus is pretty low to begin with. I did some tests a while back, I setup a 6ft long link and ran for several days of continuous music checking the CRC and never got a single error. I repeated this with a 15ft link and the same thing. I then strung together two "extension cords" to get about 30ft and THAT gave a few errors a day.

 

So even though UAC has no error correction it is not that big a deal in most situations.

 

John S.

 

Yet, I think many folks suppositions about USB audio rest on the idea that this is not true, though I am not sure if this idea exceeds the idea that "noise" is being passed by USB - though I have not heard an explanation as of yet (I am sure there is one) as how exactly the DAC processes this electrical noise into something audible (i.e. confuses it for data/bits). Perhaps the DAC is merely passing it on to the amp to be heard?

[crenca]

Have you tried using a linear power supply and a regen on your USB keyboard?

 

Stop! my side hurts!

[crenca]

Saving bandwidth is usually not the main reason for using UDP. For real-time streaming, TCP can actually be a problem because of its reliability guarantees. If a packet is dropped, TCP will stall the transfer and request retransmission, which ends up causing a much longer drop-out than the a lone lost packet would. By the time you get the retransmission, the packet is too old anyway and you have to discard a bunch of following ones too in order to catch up. For non-real-time streaming (e.g. audio/video on demand), TCP together with a rather large local buffer tends to be the simplest to implement. Provided packet loss is not too severe, the buffer will hide the interruptions in the data stream whenever TCP needs to retransmit.

 

I must be missing something, why does this not work for audio (a buffer of sufficient size that TCP re-transmissions could get put back in order in time for processing by the DAC)? Are you talking about assuming buffer in the > 1 second range? I would think even in a "mediocre" home wifi situation (where TCP re-transmissions are of a non trivial amount) this would work.

 

As an aside, the UDP comparison has me wanting to jump to the anti-USB camp...

[crenca]

For something like a phone call a buffer of that size would add too much latency. It also doesn't work for any kind of live transmission since every lost packet will make you fall a little more behind the source and eventually a buffer of any size will run out.

 

Ah yes, Homer moment - I forgot USB audio is for other things besides my music audio...

[crenca]

Interesting you mention UDP. Most people think Ethernet means TCP/IP and all audio over Ethernet must use TCP. However, some home audio uses UDP. That said UDP is more than fine for home audio with a decent network.

 

If you are so inclined, what are some examples of these products that are using UDP? Is this usually in the specs of said products?