On USB cables and controller transfer modes (a series of questions to/replies from usb.org)

[svyr]

I've been really unimpressed by the level of speculative and anecdotal 'evidence' permeating the USB cable related threads. The levels of selective reading and blind faith spiced by unnecessary spending and delicious placebo are to say the least astounding and as always do little/no favours to credibility of audio community and vendors.

So I've decided to email http://www.usb.org/about - a non for profit forum founded by the developers of the usb specs, to find out some more authoritative answers to the questions of both USB cables and (as it turned out, I didn't ask, but the responder addressed) bulk vs async vs adaptive USB transfer modes. "If anyone would know - it's them" is my way of looking at it.

To my surprise they've replied to my initial email, and will hopefully reply to follow up questions.

You're welcome to ask any additional questions and I'll pass them along (probably more convenient for the people on the other end if it all comes from a single contact)

Of course the more selectively reading gifted of us will read in more magic and speculation, but I hope this will clear up some issues to people who really do want to know the hopefully objective facts behind it all, from people who don't have a financial interest in selling audio cables, gear or advertising in magazines. Or perhaps, while we're waiting for some objective measurements from people without vested interest/the right set of equipment and skills to conduct them.


Anyway, here are the org messages so far (waiting for a reply to the follow up atm) (my name and email removed, the email of the usb.org people separated by AT to prevent delicious spambots harversting)

-----Original Message-----

From: svyr [mailtogmail.com]
Sent: Wednesday, August 03, 2011 4:27 AM
To: admin [AT] usb.org
Subject: usb audio (class 1 and 2) and cable affecting sound?

Hello,

Major debates are raging about Class 1 or 2 USB audio devices (TE7022,
TAS1020B, etc receiver chips),
operating in adaptive or asynchronous isochronous modes being or not
being affected by
by 'quality' of the USB cable used.
(http://www.head-fi.org/forum/thread/554008/don-t-get-why-audiophile-usb-cab
le-would-improve-sound-quality/645#post_7651352)


I'm not going to bore you with much detail, but people seem to think
'audiophile' cables,
somehow improve sound quality by "reducing transmission errors and
'jitter'" over to spec/certified
USB cables.They also seem to think custom cables improve sound by
using better shielding/allegedly higher
conductivity wires.

Personally I think it's all expensive placebo and waffle and because
of the cost/margin on some of those
cables
http://www.wickeddigital.com.au/index.php?page=shop.product_details&flypage=
joomlaplates.tpl&product_id=801&category_id=80&option=com_virtuemart&Itemid=
53
fraud.

I was wondering if usb.org could comment on the issue, including any
influence they think
an after-market USB cable can have theoretically, and perhaps empirically.

Best Regards,
[svyr]

To my surprise the reply also unexpectedly addressed the issue about adaptive/async transfer modes vs bulk mode usb audio devices. I've long thought bulk mode was superior because of error detection and retransmission and it seems usb.org people are of the same opinion. You can view the org deliberations about it in http://www.head-fi.org/forum/thread/546092/confirming-whether-your-dac-is-asynchronous-as-claimed-or-not I obviously don't advocate musiland products, in fact I'm vocally opposed to their dodgy QC, and bs marketing, that's probably quite clear from say, 3 threads from me catching them on their bs . Bolds are on my side for emphasis .
-----reply 1-----
[quote name="TechAdmin [AT] usb.org"]
to svyr
date Fri, Aug 5, 2011 at 5:46 AM
subject RE: usb audio (class 1 and 2) and cable affecting sound?

Hello [svyr],

USB transmits information digitally. Bits are either received correctly or
not received. What a bit looks like on the wire has no effect on quality if
the bit is received correctly. If a bit is not receive correctly, error
checking in USB protocols will flag the error in data transmission.

Jitter is not a cable problem. Jitter is a transceiver (PHY) issue on the
devices.

Can bits get scrambled within a cable assembly on occasion? Yes, primarily
due to EMI but this is highly unlikely -- more on that later. Is occasional
data scrambling a problem for audio/video? Maybe. The answer depends on the
hardware receiving/rendering the data.

USB supports isochronous transport which is a timely delivery of data. The
isochronous transport has guaranteed bandwidth on USB. Isochronous
protocol, however, does not support error recovery. In other words, if data
is flagged as an error by the receiver, there will be no attempt at data
retransmission. So if the receiver is using the isochronous protocol, then
there can be errors in data. Most webcams use the isochronous transport.

High-end audio/video equipment that does not mandate real-time delivery of
data should not use the isochronous transport because accurate data delivery
is not guaranteed.

USB also supports bulk transport. The Bulk transport shares bandwidth and
timely delivery is not guaranteed. Bulk protocol does have error recovery
and errors in data will be retried. If the receiver uses the bulk USB
protocol, then there will be no errors in the data. This is why USB mass
storage devices always use the Bulk transport.

Most USB audio/video devices use the bulk transport because real-time
delivery of the data is not necessary. Bulk audio/video devices will buffer
data before rendering it. I can think of only two situations where the
audio/video will be disturbed when rendered: 1) If the host is busy
performing IO to other USB devices, or 2) There are errors in data
transmission where continual retries cause buffer under-run to occur. The
second point could be cable related -- it could also be poor hardware design
of the host or peripheral as well. The USB Bulk transport works very nicely
for audio and video because data is accurately delivered.

Now onto cable quality. A cheap USB cable will work perfectly fine in the
vast majority of home/office environments. All USB certified cables use
certified connectors and are shielded, have minimal skew on the data lines,
and meet criteria regarding impedance and voltage drop. If the environment
is extremely noisy with EMI, then a better shielded cable may be necessary.
Usually relocating the cable or power strips will suffice to mitigate EMI.

Personally, I would never recommend anyone buy an expensive USB cable unless
they are experiencing problems not related to their hardware and there
exists definitive suspicions of environmental interference. I do always
recommend that the cable purchased be USB certified which provides assurance
that the product is properly designed for USB. Using USB certified
audio/video equipment also assures that the USB signal quality and other
packet parameters of the transceiver meets specifications.

Of course, all of the above is premised upon properly designed and
functioning hardware.

Regards,
Mark Paxson
USB-IF Compliance Administrator
TechAdmin@usb.org
(ReplyID 110804.105337)

Please visit http://compliance.usb.org for the latest updates to the USB-IF
Compliance Program.


[/quote]

again, I trust that's about as clear as it could be about cable jitter, and transfer modes. More info about usb transfer modes and adaptive vs bulk vs async and the associated lack or presence of error detection and correction is in. http://www.head-fi.org/forum/thread/546092/confirming-whether-your-dac-is-asynchronous-as-claimed-or-not I obviously don't advocate Musiland, in fact I'm vocally opposed to their dodgy QC, and bs marketing, that's probably quite clear from say, 3 threads from me catching them on their bs

Anyway, I thought I'd ask a few more questions:

-----follow up message-----

[svyr] [AT] gmail.com
TechAdmin [AT] usb.org
date Fri, Aug 5, 2011 at 10:08 AM
subjec tRe: usb audio (class 1 and 2) and cable affecting sound?



Hello Mark,

Thank you very much for a detailed reply on the topic of USB audio!

It's good to see that my interpretation of the USB spec regarding Bulk
vs adaptive and async usb
transfer modes was correct. (including the bit about error correction
in bulk mode and it's absence for guaranteeing delivery latency in the
other isochronous transfer modes). I would assume the only time bulk
mode might not be so good, is if you for some reason need a guaranteed
latency both ways and there are transmission errors... Or maybe
something to do with the reserved bandwidth for modes other than bulk
(I presume that may impede its use in applications where you need
bidirectional streaming like pro audio recording and simultaneously
monitoring, but I'm not too sure about that either. I think I just
have to get out of the habit of assuming transmission errors are
common and out to get us).

I think it's somewhat unfortunate that nearly all the consumer grade
USB audio devices I looked at were using
adaptive and in best case async modes.
It's I've recently purchased a musiland md series card that
uses bulk mode - custom drivers to view the usb receiver on its end
as a separate bus on the usb bus (bulk mode PC to the receiver), and
then attaches the audio device on that bus.

Unfortunately, as far as I know this is the only bulk mode USB
transfer mode consumer grad card out there (along with other musiland
series cards). If you know more consumer or pro grade ones, could you
please name one or two as examples?

It's good to know my interpretation of the error correction (bulk mode
only, and I presume error checking on receipt and retransmission on
error?)
and the circumstances where it stops helping (although adaptive and
async wouldn't be of use there either it seems) are also correct
(buffer under-run on either the receiver or sender side, either
because the host is busy or in the unlikely scenario the transmission
is bad because of a very high error rate and retransmission doesn't
rectify it (or maybe cannibalizes too much from the useful bandwidth)
at that stage you probably would have more problems than not being
able to guarantee latency even softly and you probably won't hear much
if it was an adaptive or async device at that point anyway). Not that
latency seems to be much of a problem for playback applications.

> If the environment is extremely noisy with EMI, then a better shielded cable may be necessary.
Usually relocating the cable or power strips will suffice to mitigate EMI.


Hmm, interesting, thank you. Ummm, I don't know how feasible is it,
but could you maybe name some common household sources you'd generally
find in a home office type environment, that could have high enough
EMI to warrant that.


Once again, thank you very much for the interesting and extended reply !

Best Regards,
[svyr]

So I'm currently waiting for a reply to those...

I hope this sheds some objective light on the usb cable issue, and will make more USB audio makers get off their lazy backsides and make DACs with proper bulk transfer mode USB implementations (I can't be angry enough with musiland being the only one from the audiophile market to date that do it)...Writing drivers is difficult, especially for multiple OSes, but is it a good enough reason to continue making adaptive/async usb transfer mode DACs instead of bulk mode ones.

 

[svyr]

reserved for future replies 1

 

[svyr]

reserved for future replies 2 just in case

 

[Prog Rock Man]

Brilliant svyr. So we have it from those who really know, the cable either works or it does not, other than that it has no effect on the signal/data.
 
Jitter is such a red herring when it comes to cables, it is an issue between the sender and receiver and has nothing to do with the cable.

 

[Roseval]

Isochronous mode reserves bandwidth.
Sound good but is bandwidth on the hub.
What is upstream is as far as I know not covered.
 
Playing audio is having some media player selecting a song.
It is processed by a codec, the output is stored in memory and spooled from memory to the USB hub.
Whatever happens with CPU or on the PCI, it might interrupt the flow to the hub.
We do have reserved bandwidth on the USB but not guarantee the hub will be feed in time.
That’s inherent to a multitasking system.
 
We can change from isochronous to bulk mode.
Now even the USB performance is no longer guaranteed.
Will this be an improvement?
 
It is pretty common when using streaming AV not to have a retry, be it isochronous USB or UDP over a network.
Often the latency of the network is too high for a retry to make sense, it probably arrives too late.
With bulk mode and a small buffer this might be the case as well.
 
If we do bulk mode, we probably need a substantial buffer to avoid buffer under run.
As a consequence, latency might be high.
We press stop in out media player and it last a couple of seconds before the DAC has drained its buffer.
 
I must admit the first time I read about isochronous mode I was a bit surprised.
Error checking is possible but retries not, pretty much like stone age SPDIF!
On the other hand, how many errors are generated?
In general bit flipping in audio is clearly audible, it is POP.

I do think the number of errors are very small.
Makes me wonder if trading in reserved bandwidth for retries for is an improvement.

 

[NA Blur]

Very informative thanks for sending the emails.

 

[svyr]

Isochronous mode reserves bandwidth.
Sound good but is bandwidth on the hub.
What is upstream is as far as I know not covered.
 
Playing audio is having some media player selecting a song.
It is processed by a codec, the output is stored in memory and spooled from memory to the USB hub.
Whatever happens with CPU or on the PCI, it might interrupt the flow to the hub.
We do have reserved bandwidth on the USB but not guarantee the hub will be feed in time.
That’s inherent to a multitasking system.
 
We can change from isochronous to bulk mode.
Now even the USB performance is no longer guaranteed.
Will this be an improvement?
 
It is pretty common when using streaming AV not to have a retry, be it isochronous USB or UDP over a network.
Often the latency of the network is too high for a retry to make sense, it probably arrives too late.
With bulk mode and a small buffer this might be the case as well.
 
If we do bulk mode, we probably need a substantial buffer to avoid buffer under run.
As a consequence, latency might be high.
We press stop in out media player and it last a couple of seconds before the DAC has drained its buffer.
 
I must admit the first time I read about isochronous mode I was a bit surprised.
Error checking is possible but retries not, pretty much like stone age SPDIF!
On the other hand, how many errors are generated?
In general bit flipping in audio is clearly audible, it is POP.

I do think the number of errors are very small.
Makes me wonder if trading in reserved bandwidth for retries for is an improvement.

that's pretty much why I asked him whether the reserved bandwidth on async/adaptive mode for playback is necessarily a good thing.

As for you hypothesis. I don't think the 'POP' is flipped bits. You'd have to drop quite a few samples for it to be audible, so it's a lot more plausible it's buffer under-run.


>It is pretty common when using streaming AV not to have a retry, be it isochronous USB or UDP over a network. Often the latency of the network is too high for a retry to make sense, it probably arrives too late. With bulk mode and a small buffer this might be the case as well.

heh, while the idea is the same, comparing multi-hop and large distance protocols to USB is a bit far fetched... That said, we could always have a look at what the control message+data transmission round trip times are for bulk mode using something like USBTrace. But as you pointed out, it would depend on the buffer size and the initial playback delay.



>We do have reserved bandwidth on the USB but not guarantee the hub will be feed in time.

that's of course correct, and would be a buffer underrun



>If we do bulk mode, we probably need a substantial buffer to avoid buffer under run. As a consequence, latency might be high.We press stop in out media player and it last a couple of seconds before the DAC has drained its buffer.

not really. at least not on MD30 or MD11 that operate in bulk mode. I think it just sends a control message saying 'stop playback' rather than draining the buffer.
For starting playback the delay is not really noticeable or more than adaptive mode DACs either, I presume, there is more than enough bandwidth (the theoretical max of 60MB/s, when 2ch 192k/24b is about 1MB/s) to go around to compensate for any buffering (well, there would some overhead for in out but that seems like it's negligible). Pretty hard to speculate about it not knowing what the buffer and latencies around it are, but there is definitely enough bandwidth to go around.

We can (might) also find out the buffer size by checking the specs for the MD30/11 chips (assuming they don't have anything else downstream). http://www.cypress.com/?docID=30172 the USB controller, and the FPGA that it outputs to http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf for further processing: and that yields a whopping 4K for the usb chip (+16K ram, but some of it is used ) , and I can't make much sense of the FPGA one (IOBs buffer of some sort? or block (216k over all blocks?) or distributed (shared between blocks?) RAM (38K)... Depends how the data is processed or stored and I'd assume it's in parallel blocks, and what the role of IOB is, it's pretty hard to make sense of what can actually be used as a buffer in the FPGA ). So either there is a larger buffer somewhere, or FPGA processes the data quickly enough (the rated figure is about 80MB/s) and it keeps getting refilled in time from the pc side into the controller and or FPGA.

Anyway, I'll ask musilol

 

[DaBomb77766]

Interesting, but not in the least unexpected.  This is what I've been saying all along.
 
Could you ask them if the new USB 3.0 spec could hypothetically offer any improvements for this sort of thing (audio/video)?

 

[Roller]

So far, USB 3.0 is very much advised against being used for audio, with a lot of issues arising on many different hardware, from audiophile and DJ DACs, up to pro audio gear, all displaying crackling, dropouts, and other issues. I have no idea what could be the reason behind this, but it was theorized that there could be some voltage imbalance when feeding devices through the ports.

 

[DaBomb77766]

Quote:

So far, USB 3.0 is very much advised against being used for audio, with a lot of issues arising on many different hardware, from audiophile and DJ DACs, up to pro audio gear, all displaying crackling, dropouts, and other issues. I have no idea what could be the reason behind this, but it was theorized that there could be some voltage imbalance when feeding devices through the ports.

Hm, doesn't it just revert entirely to 2.0 mode when using USB 2.0 cables?  Or are the ports really physically different aside from the extra pins?

Anyway, I really just meant for if people started using USB 3.0 from the client side as well.  A USB 3.0 cable wouldn't even be compatible with the current hardware, since the B and mini-B connectors are completely different.

 

[Roller]

Quote:

Hm, doesn't it just revert entirely to 2.0 mode when using USB 2.0 cables?  Or are the ports really physically different aside from the extra pins?

Anyway, I really just meant for if people started using USB 3.0 from the client side as well.  A USB 3.0 cable wouldn't even be compatible with the current hardware, since the B and mini-B connectors are completely different.

Well, I would assume that simply falling back to 2.0 would make the ports work as expected under 2.0 specs, but there are issues (possibly power related) that cause chaos on audio interfaces.
 
To my knowledge, there aren't any DACs with USB 3.0 anywhere, specially since there is no need for more bandwidth than what USB 2.0 supplies.

 

[DaBomb77766]

Quote:

Well, I would assume that simply falling back to 2.0 would make the ports work as expected under 2.0 specs, but there are issues (possibly power related) that cause chaos on audio interfaces.
 
To my knowledge, there aren't any DACs with USB 3.0 anywhere, specially since there is no need for more bandwidth than what USB 2.0 supplies.

 
Okay, that's what I thought.  I'm wondering more about if a USB 3.0 signal would have more tolerance for error or something like that, rather than just bandwidth...because even USB 1.0 has enough bandwidth for audio.

 

[svyr]

i think you guys misunderstand the usb spec a bit. the usb audio standard is separate to usb 3 and has not been updated with the release of usb 3.

there is at least one dac that uses usb 3 connectors - musiland us 03. the chip is still a usb 2 one, but it takes advantage of the higher electrical power available for usb 3. musiland quotes up to 2w output from HP out is possible vs less than 1w (? see the exact numbers in the thread) think you guys misunderstand the usb spec a bit. the usb audio standard is separate to usb 3 and has not been updated with the release of usb 3.

it really seems like the only thing you can get from usb3 is a more powerful HP amp.

 

[DaBomb77766]

Quote:

i think you guys misunderstand the usb spec a bit. the usb audio standard is separate to usb 3 and has not been updated with the release of usb 3.

there is at least one dac that uses usb 3 connectors - musiland us 03. the chip is still a usb 2 one, but it takes advantage of the higher electrical power available for usb 3. musiland quotes up to 2w output from HP out is possible vs less than 0.5w (? see the exact numbers in the thread) think you guys misunderstand the usb spec a bit. the usb audio standard is separate to usb 3 and has not been updated with the release of usb 3.

it really seems like the only thing you can get from usb3 is a more powerful HP amp.

Well, the cables are different, and the cables are a spec.  That's what I was really referring to, not to the actual data transfer spec.

Anyway, I'd forgotten about the higher amount of power a USB 3.0 port could give out - I guess that's a definite advantage.

 

[svyr]

Well, the cables are different, and the cables are a spec.  That's what I was really referring to, not to the actual data transfer spec.

Anyway, I'd forgotten about the higher amount of power a USB 3.0 port could give out - I guess that's a definite advantage.

Hmmm, USB 3 might possibly have better shielding if it can handle higher power...I'll ask usb.org
Might ask them about the USB isolators a-la

http://www.olimex.com/dev/usb-iso.html
http://www.fioboards.com/amg-usb-isolator.html

as well. (although that might be more of a question for Analog Devices, who produce the ADUM5000 ADUM4160 chips.