USB cables and me

Discussion in 'DACs' started by gvl, Aug 7, 2017.

  1. gvl

    gvl Well-Known Member

    Messages:
    987
    No, the data is sent over separate conductors from power. I respect my own opinion but I also realize it is purely subjective, unfortunately I couldn't find any solid lab data to back it up, perhaps I didn't look hard enough, I will try more. What I do know it is not all 0s and 1s, as some have suggested.
     

     

    Please register to disable this ad.

  2. gvl

    gvl Well-Known Member

    Messages:
    987
    There are 2 different products, the Premier SE uses thicker 23AWG silver plated copper conductors and USB-AG is 24AWG solid silver, the former is more expensive tho, I got the latter. I suspect it is the length of the cable that's more important than everything else.
     
  3. bshorey

    bshorey Super Member

    Messages:
    3,716
    Location:
    Gilroy, CA, USA
    <snip>

    Pins 1 and 4 carry power, pins 2 and 3 carry data.

    bs[/QUOTE]
     
    Last edited: Aug 7, 2017
  4. gvl

    gvl Well-Known Member

    Messages:
    987
    Apart from bit-correctness there is also jitter, and unless the USB input of the DAC supports asynchronous mode (I think mine does but need to verify) a marginal USB cable can introduce additional jitter.
     
  5. bshorey

    bshorey Super Member

    Messages:
    3,716
    Location:
    Gilroy, CA, USA
    I think jitter is a function of the clocks on either end, and not the cable, correct? Regardless, I don't think jitter is an issue in this application, as buffering on either end should more than suffice to get the bits all to their destination in plenty of time.

    Yeah, a marginal cable can introduce all kinds of problems. That's true with any kind of cable.

    bs
     
  6. gvl

    gvl Well-Known Member

    Messages:
    987
    My casual research into this tells me that both synchronous and adaptive USB modes derive the clock from the actual signal on the cable and slopey signal edges on less than ideal cables can cause additional jitter. The adaptive mode is supposedly can be made very jitter resistant but not jitter free. The asynchronous mode is the only mode that can be jitter free as the destination device always runs off its own fixed clock and controls the speed of the transmission by sending feedback to the host to ensure the receiving buffer over/underrun doesn't occur.

    Found this puppy: https://www.passmark.com/products/usb3loopback.htm
    The price is accessible and looks interesting but it won't report jitter, so not entirely useful for USB audio testing.
     
    nyhifihead likes this.

     

    Please register to disable this ad.

  7. bshorey

    bshorey Super Member

    Messages:
    3,716
    Location:
    Gilroy, CA, USA
     
  8. bshorey

    bshorey Super Member

    Messages:
    3,716
    Location:
    Gilroy, CA, USA
    There are clocks on both ends of a USB circuit.

    It is the job of the clock on the sending end to send data at the appropriate bitrate. I believe that the receiver derives the bitrate, not the 'clock', from the incoming signal. There should also be circuitry on the receiving end to factor out any jitter and package up the incoming bits according to that bitrate.

    As long as both ends are doing their job, and the receiving end is ending up with the same bits that were sent, then jitter is not a factor. You could have a ton of jitter, but if the receiver can correctly align the incoming bits such that they match what was sent, then it's a non-factor. If there is enough jitter that the receiver can't properly reassemble the bits properly, then you have a problem.

    bs
     
  9. gvl

    gvl Well-Known Member

    Messages:
    987
    Jitter-correction is generally not bit-accurate, and excess jitter on the receiving end may lead to additional information loss. Only in asynchronous mode there should be no need for jitter correction as the receiver can control how much data it receives and it can keep its receive buffer filled as needed and send bits exactly as received further onto the DAC chip.
     
  10. bshorey

    bshorey Super Member

    Messages:
    3,716
    Location:
    Gilroy, CA, USA
    Ok, but again, unless there's some actual problem with a cable, connection, or hardware on either end, jitter is not usually a large factor in USB audio. And if you do drop a bit, there's still a CRC check and a retransmission, right? I haven't worked at the bits and bytes level of USB for a long time now (1.0/1.1), but even back then there were plenty of mechanisms in place to ensure that the bits arrived intact and in proper order.

    bs
     
  11. gvl

    gvl Well-Known Member

    Messages:
    987
    There is no re-transmission in Isochronous Transfer mode, the best receiver can do is CRC-check and and drop broken sample(s) and interpolate. Seems that USB jitter is actually a problem, or at least was in the early days. Now that the problem is well understood there are solutions to deal with it. Still, less jitter to begin with is always better I would think.
     

     

    Please register to disable this ad.

  12. bshorey

    bshorey Super Member

    Messages:
    3,716
    Location:
    Gilroy, CA, USA
    I'm a little confused. Who uses pure isochronous mode to transmit audio (or any kind of data)? Doesn't somebody use isochronous transfer, along with the control and interrupt functions, to implement synchronous or asynchronous communications?

    Fully agree that less jitter is always better. Less problems of any kind are always better.

    bs
     
  13. gvl

    gvl Well-Known Member

    Messages:
    987
    http://www.xmos.com/fundamentals-usb-audio
     
  14. bshorey

    bshorey Super Member

    Messages:
    3,716
    Location:
    Gilroy, CA, USA
    Interesting read. But the isochronous, control, and interrupt mentioned are the raw USB interfaces, or building blocks. If you scroll further down, they talk about sending extra sample data (8 extra samples per second). Doesn't this indicate that something at the receiving end is doing something with those samples to ensure data accuracy?

    bs
     
  15. gvl

    gvl Well-Known Member

    Messages:
    987
    I think what this means is that the sender can safely stuff 8 extra samples per second and not cause an overflow (or rather a buffer overrun) on the receiving end.
     
  16. bshorey

    bshorey Super Member

    Messages:
    3,716
    Location:
    Gilroy, CA, USA
    Sure, but what happens with those extra samples? The fact that you're sending any extra data indicates that the receiver is not blindly passing bits to it's DAC, it must be doing something with all of the incoming data before passing any of it along, otherwise the extra sample data would disrupt the audio signal. I've got to think that something is being done with the extra sample data is to perform some level of integrity check on what you're getting, to make sure that what you're getting is what was sent.

    Now I'll have to go looking to see if there's anything depicting the data and control logic for an actual audio app.

    bs
     

     

    Please register to disable this ad.

  17. gvl

    gvl Well-Known Member

    Messages:
    987
    I think it is actually blindly passing bits to its DAC, as the receiver clock frequency is the clock frequency of the DAC.
     
  18. bshorey

    bshorey Super Member

    Messages:
    3,716
    Location:
    Gilroy, CA, USA
    I don't see how it can, if there's extra sample data being sent, something has to at least make a decision to toss that.

    Time for some reading. I'm obviously out of data on this. Interesting discussion, btw.

    bs
     
  19. gvl

    gvl Well-Known Member

    Messages:
    987
    No, the receiver is the master, if the sender has put an extra sample it means the receiver needs it as it spins slightly faster than the sender.
     
  20. pete_mac

    pete_mac Super Member

    Messages:
    2,781
    Location:
    Sydney, Australia
    There's definitely no laughter from me... only an acknowledging nod.

    Both the Curious USB cable and a DIY effort with solid silver data lines (shielded) and a separate solid copper ground line (shielded) but no +5V line (as it is not required in my application) sound better than the generic USB cables that I have used in the past. It's not a huge difference, but readily detectable. Once you've used the 'better' cables for a while, if you switch back to the generic cables, it's easier to detect the difference IMHO.

    I've also compared these two cables against the solid USB A to B coupler that came with my Uptone Regen (and was touted as being better than any cable at the time) and the coupler is better than a generic cable, but not as good as the others.
     
    SWL3600 and gvl like this.

Share This Page