1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.

    Dismiss Notice

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

Discussion in 'Computer Audio' started by svyr, Aug 5, 2011.
2
Next
 
Last
  1. 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-----

    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-----

    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.
     
    skeptic, BlackbeardBen and plakat like this.
  2. svyr
    reserved for future replies 1
     
  3. svyr
    reserved for future replies 2 just in case
     
  4. 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.
     
  5. 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.
     
  6. NA Blur
    Very informative thanks for sending the emails.
     
  7. svyr

    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 :D) , 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 :D ). 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 :D
     
  8. DaBomb77766
    Interesting, but not in the least unexpected.  This is what I've been saying all along. :p
     
    Could you ask them if the new USB 3.0 spec could hypothetically offer any improvements for this sort of thing (audio/video)?
     
  9. 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.
     
  10. DaBomb77766


    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.
     
  11. Roller


    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.
     
  12. DaBomb77766


    Quote:

     
    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.
     
  13. 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.
     
  14. DaBomb77766


    Quote:


    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.
     
  15. svyr

    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.
     
2
Next
 
Last

Share This Page