[fenixdown110]

True. The best is to just use better wire and shielded cables.

 

[scootermafia]

Yeah, I have USB cables that came with pre mounted ferrites. Maybe they are out of spec (like the controller charge cable for my PS3). In any case, my Cardas Clear USB comes on Tuesday (only about $120 or so for a meter) and is said to boast all manner of elite secret technologies. I've built plenty of my own USB cables, so we'll see how this one stacks up.

 

[wavoman]

I'm only reporting what's on USB Org ... I have no idea. I have a Cardas USB cable with a ferrite too (got it cheap, but before I read the FAQs).

 

[dvw]

Quote:

Originally Posted by oddity /img/forum/go_quote.gif A Quick Note: Bits n’ Bytes The deficiency in this interface is that it embeds the serial clock in the serial data-stream in order to achieve one-signal cabling. A superior interface would have included both a clock and a data signal, but we don't have this, so we live with S/PDIF. The S/PDIF interface must encode the data and clock into a single signal and then at the destination recover the clock(s) from the data-stream. The process of recovering the clocks can introduce new jitter since there is usually a PLL involved. Jitter and USB There is much misinformation on the forums about USB for audio streaming. USB is a fairly jittery interface on it's own. Some of the integrated circuit devices that were created to provide easy plug-and-play USB audio interfaces don't do enough to reduce USB jitter IMO. Many manufacturers adopted these plug-and-play devices to quickly and cheaply add USB to their DAC products. Unfortunately the less-than-stellar reviews that ensued had some of these manufacturers regretting these decisions. This gave USB a bad name in many circles. Fortunately, there are other low-jitter USB interfaces available now that not only support 24/96, they even compete with the best CD playback devices. In 2009, I believe we will see USB support for 24/192 and even lower-jitter interfaces. USB is IMO the wired audio interface that will be most prevalent in the near future. The Really Technical Parts: Isochronous Transfers The Terrors of the Isochronous Mode We have a problem. It is a problem with a USB mode: in the adaptive isochronous audio transmission mode, the receiver has to determine the bit rate. This means that the bit rate is unknown prior to the time the data arrives. The bit rate cannot be known prior to actually observing the packet. Another terror of USB is that, according to the specification, it would not be unusual for the bit rate to change when the operating system is busy. Since the packets arrive on 1 kHz intervals, the PLL must lock within 1ms. In most PLLs, if we say that 1 kHz fluctuations are clearly audible and decrease the gain, we cannot track! Terror of terrors, we have just bumped into a brick wall. In reality, fluctuations in the time domain will probably result in an unpleasant listening experience. This is probably because they are delaying the lock-up time in order to reduce the jitter distortion. Also, for isochronous USB data, a buffer is necessary for the time between the beginning of the packet until PLL lock, so the PLL lock-up time is reflected directly in the chip cost. The more audio quality is pursued, the longer the necessary buffer and the longer the time lag when playback begins. On the other hand, if the time constant of the loop filter is increased, a large RC is necessary and the chip area increases (recent progress in semiconductor technology has brought about minimization of digital devices, but analog devices have not changed).

There is a lot of data here and I do appreciate the hard work done by the OP.

I have a lot of questions here. This is somewhat technical. I hope you guys don't mind.
1. The OP seems to suggest separate clock and data signal is better than embedded clock. What is the theory behind it? How about clock skew?
2. There is suggestion a better USB interface is coming. How? From what standard body?
3. OP also seems to suggest that audio is in isochronous mode transfer and is not accurate in high speed. Why is that? as I see in the appendix , bulk transfer is even faster. How is it possible accuracy is reduced? In
4. OP also seems to suggest that isochronous transfer is 1 KHz continous. PLL lock time of 1 ms is difficult. But appendix showed all transfer are in packets, the USB clock should not matter as the data and the playback are asynchronous. The playback clock has to be synchronized to the record clock anyway or you'll have buffer over/underflow issue. In this scenario the jitter of the clock from the USB interface will not matter, right?
5. The last part of the post gives the impression that the USB specification is broken. I sure hope that's not the case.
I don't know how to use the multi-quote. Please excuse me for the format of the quote.

 

[edisonwu]

Thank you! I am reading!

 

[kite7]

"This is worth a read" bump. Great post

 

[angrylion]

It would save EVERYONE a lot of time and trouble (not to mention cost) if the pictures in post #6 were consistent: http://i869.photobucket.com/albums/ab259/kvnsnyder/USB-cable-wiring.jpg is the clearest/easiest one to use, but WRONG: D+ and D- are swapped!
 
BTW: ferrite beads come in several flavours...
The ones that are clamped on the outside of the cable do absolutely nothing with the signals inside the cable. They are used to prevent HF noise (like cellphone interference) entering into equipment (or radiating from, as with computers and switch-mode power supplies).
Another type is connected in series with each wire: they actually attenuate HF (beit noise or wanted signal) in the circuit they are inserted into, but most of them are only effective from 1MHz up (in other words: do not affect pure audio signals). Mostly used for 'cleaning up' power and low-speed control lines.
There is an intermediate form that is used for twisted pair and the like: a sort of transformer known as balun. These are best suited for high-speed signals like USB and IEEE1394.