With your average USB interface like the XMOS or CMedia 663x, the data is not subject to "inherent timing variations" until it is clocked out of the buffer by the local master clock. Whatever happened on the way to the XMOS IC over the USB interface contributes nothing to the jitter of the conversion clock.
This seems to me a plausible explanation with scientific reasoning and a test protocol.
Especially so because those who report differences seem to find them regardless of cost. As he said, Russian roulette.
And I’ll say it: Forget audio. I don’t trust USB in any kind of enterprise environment for anything but MAYBE a printer if I’m hard pressed, period.... end of story. Not reliable.
The new USB-C technology may make strides here. I haven’t used it yet for audio.
Audio over thunderbolt was an eye-opener for me though in comparison.
USB has / had real issues both in its hardware and it’s drivers. Partly it’s an issue with its ubiquitousness / a lack of quality control. I personally feel Intel dropped the ball.
However as always snake oil pervades were understanding is limited.... but because there is snake oil doesn’t require that there be no problem worth addressing in the first place.
PS I don’t have any experience with hearing tests between usb cables because I try to avoid them entirely and when using them for convenience I’m not really evaluating them in isolation.... so take it for what it’s worth.
Last edited:
Amir at audiosciencereview took some jitter measurements using a Schiit DAC and various USB cables at one point.
There are clear measured differences between the different cable used, although IMHO it's be hard to believe at the levels we're talking these could be audible.
There is also speculation in the linked thread that effects like this may only be observed when the DAC's USB implementation is lacking.
There are clear measured differences between the different cable used, although IMHO it's be hard to believe at the levels we're talking these could be audible.
There is also speculation in the linked thread that effects like this may only be observed when the DAC's USB implementation is lacking.
It depends on a lot of factors. I have seen USB used in a medical application and had zero bus resets, corrupted frames, etc. while undergoing EMC immunity testing and ESD testing. I have also seen devices with mistakes that cause it to be very fragile. You are right that the audio device class and the audio drivers can be flaky. The USB spec (especially newer additions / Type-C) is a kitchen sink of design-by-committee which makes it hard to test and guarantee interoperability with all the corner cases.
Thunderbolt is really just external PCIe and DP over the same cable. It's nice to have external PCIe. Hopefully it will spur the design of new of PCIe audio interface ICs to replace some of the few that are still available.
Thunderbolt is unfortunately more Intel / cartel-style nonsense like the HDMI racket. No one besides Intel can make TB transceivers and you need to be qualified as a "Thunderbolt Developer" to get access to documentation and purchase most of the chips. Intel has open registration but good luck getting them to respond. I have seen them ignore legitimate requests from a very large organization. Even if you get the chips and make it all work I am not sure you can market a device without their approval.
Last edited:
Yes, the differences went away when the Schiit DAC was replaced with a $79 Behringer UMC204 HD.
I agree, and I think you understand my point.
PCIe and DP over the same cable sounds great to me, personally. For those who shoot video on site it’s a game changer.
Unfortunately thunderbolt seems to be getting absorbed into the USB-C design from my understanding... most likely due to lack of thunderbolt adoption. This could go a couple of ways and really hope it doesn’t go south as while it was expensive, rare and somewhat obnoxious Thunderbolt was rock-solid.
So, pick your poison- design by committee or cartel control.
I’m providing an example of the product’s end result in a specific application not an assessment of their general business practice.
I could have used another technology to make my point but I did not have real world experience in an audio application.
The fact remains: USB has real hardware and software problems that are far better mitigated in other solutions.
Whether USB issues described above are audible I have no opinion. However, if some cable type were to have audible problems from a wide range of manufacturers my money would be on it being USB as I’ve experienced a wide range of functional issues in different applications.
As I said- I will not trust anything mission critical over USB.
Enterprise solutions don’t utilize USB for good reasons.
Hopefully USB-C gets its act together.
Last edited:
Exactly. Which although cheap is an excellent DAC
Yes. The Schiit should be capable of the same performance since it uses the CM6631A, but apparently it is not well executed.
As promised.
The reference of the DRAKA (Prysmian Group) is F 4709-17.
Test equipment:
- 2GHz Oscilloscope 10GS/s WAVERUNNER 204Xi LECROY
- Active Differential Probe WL300 LECROY
- USB Test Fixture TF-USB LECROY
According USB-IF compliance program (http://www.usb.org/developers/compliance/):
--> Overall result: pass!
- Signal eye: eye passes
- EOP width: 7.89 bits: EOP width passes
- Measured signaling rate: 480.0834 MHz: signal rate passes
- Rising Edge Rate: 1005.11 V/us (636.74 ps equivalent risetime): passes
- Falling Edge Rate: 974.79 V/us (656.55 ps equivalent risetime): passes
- Consecutive jitter range: -81.928 ps to 131.408 ps, RMS jitter 49.613 ps
- Paired JK jitter range: -55.155 ps to 59.024 ps, RMS jitter 16.807 ps
- Paired KJ jitter range: -65.229 ps to 61.868 ps, RMS jitter 16.529 ps
Images attached.
ESD protection is RCLAMP0502N.
EMI CMC is DLW21S.
JP
The reference of the DRAKA (Prysmian Group) is F 4709-17.
Test equipment:
- 2GHz Oscilloscope 10GS/s WAVERUNNER 204Xi LECROY
- Active Differential Probe WL300 LECROY
- USB Test Fixture TF-USB LECROY
According USB-IF compliance program (http://www.usb.org/developers/compliance/):
--> Overall result: pass!
- Signal eye: eye passes
- EOP width: 7.89 bits: EOP width passes
- Measured signaling rate: 480.0834 MHz: signal rate passes
- Rising Edge Rate: 1005.11 V/us (636.74 ps equivalent risetime): passes
- Falling Edge Rate: 974.79 V/us (656.55 ps equivalent risetime): passes
- Consecutive jitter range: -81.928 ps to 131.408 ps, RMS jitter 49.613 ps
- Paired JK jitter range: -55.155 ps to 59.024 ps, RMS jitter 16.807 ps
- Paired KJ jitter range: -65.229 ps to 61.868 ps, RMS jitter 16.529 ps
Images attached.
ESD protection is RCLAMP0502N.
EMI CMC is DLW21S.
JP
Attachments
Yeah. The software problems are driver and driver interaction related. They mostly cause dropouts or crash the PC with a blue screen or kernel panic. When it works, it works though. The physical and lower protocol layers of USB are robust enough. How often do the interrupt transfers from HID devices fail? The answer is practically never. The functional issues you mention are from bugs in software and firmware but they are gross and noticeable issues, nothing insidious. Some controllers seem to have problems with isochronous transfers. If you think Intel is bad then just try a few ARM SoCs in Linux.
The reason Thunderbolt was rock solid for you is that the PCIe interfaces are robust and the vendors have to do their own thing - they aren't trying to implement crap like USB Audio Device Class 2.0 that presents a uniform interface to any system. I am sure it works really well if you stick something like a CMedia CM8888 in a box, though I suspect companies like RME will do their usual FPGA implementation. The latency would probably be nice for pro applications. I thought about DIYing a Thunderbolt interface but I don't have the spare time and can't get hands on the datasheets.
Nice, I have used that same common-mode choke on a USB interface (different ESD protection though). They are missing from many audio designs.
And why do you think a CM choke is needed? Because the cable is carrying high speed USB differential signalling & the cable CAN INDUCE CM noise at the USB receiver IC - it's not simply transmitted from the source. Therefore in this one factor alone USB cables can differ, never mind all the other factors
Last edited:
It might be needed to pass emissions or immunity testing on a case by case basis. A nice to have if you don't have signal integrity problems with it populated. I'd use it, but highly doubtful it has any measurable impact on the analog output. You still have yet to describe the mechanism by which this ends up in the analog output on a piece of correctly designed gear.
There are specs for USB cables you know? They specifically discuss things like the required shield construction, twist pitch, etc.
Maybe you should get in the audiophile Ethernet cable business before that blows up.
You now have altered your argument to admitting that there are difference between cables but doubt they have any "measurable impact on the analog output." Very interesting shift from your first rant about this
So, what is the effect of CM noise in audio? Have you ever measured the effect of cm noise on a DAC's analogue output?
I don't have to describe anything other than the possible differences between USB cables, as I have done. As I stated from the start I have heard some differences with ferrite clamps on USB cables & a USB cable (not designed for audio) designed ferrite compound wrap
Yes, there are USB specs which are meant to ensure a certain level of reliability in USB digital signal delivery. Tell us what it says about shield construction & twist pitch in the USB specs
Last edited:
I haven't shifted at all on cables. You can continue tilting at windmills. A total non issue in gear that is correctly designed. You can find the USB cable specifications on Intel's website.
Guys -may I make a suggestion / observation:
You have been baited into a worthless debate by an OP who makes a practice of this kind of thing. 6 months or so ago, he was whiling away his time in a thread on the loudspeakers forum essentially trying to claim AC is not alternating, that all electrical circuits are created based on Spice models (including those created before electronic computers even existed), and that a given loudspeaker crossover will behave differently if a series component were placed in the nominal positive or negative leg (no changes to electrical component order, and independent of external influences e.g. mutual inductance interactions which is a matter of board layout / component configuration rather than the electrical topology of the circuit). No support, no evidence (hardly surprising in the circumstance), just hand-waving twaddle and a rapid exit when pressed for his claimed evidence. Same modus operandi here. Paraphrasing only slightly, any of these phrases ring a bell?
-'I've... read some books [titles unspecified] & it's too complex to explain'
-'I think'
-'I believe'
-'You need to prove [despite being the one making claims -a favoured inversion of this type of troll on-line, in print or in debate]'
Do yourselves a favour: don't fall for it any further. Let the thread die now.
You have been baited into a worthless debate by an OP who makes a practice of this kind of thing. 6 months or so ago, he was whiling away his time in a thread on the loudspeakers forum essentially trying to claim AC is not alternating, that all electrical circuits are created based on Spice models (including those created before electronic computers even existed), and that a given loudspeaker crossover will behave differently if a series component were placed in the nominal positive or negative leg (no changes to electrical component order, and independent of external influences e.g. mutual inductance interactions which is a matter of board layout / component configuration rather than the electrical topology of the circuit). No support, no evidence (hardly surprising in the circumstance), just hand-waving twaddle and a rapid exit when pressed for his claimed evidence. Same modus operandi here. Paraphrasing only slightly, any of these phrases ring a bell?
-'I've... read some books [titles unspecified] & it's too complex to explain'
-'I think'
-'I believe'
-'You need to prove [despite being the one making claims -a favoured inversion of this type of troll on-line, in print or in debate]'
Do yourselves a favour: don't fall for it any further. Let the thread die now.
I had trouble with bad USB cables when re-flashing the bootloader on my android mobile. I had some "samsung" cables but they failed. The only ones that worked reliably where my Anker | #UseAnkerInstead usb cables.
idk the details of reflashing bootloader but i guess its more sensitive/less or no error correction, hence the problem. i had not noticed previous use of the bad cables being a problem with day to day use.
Note that reflashing bootloader was a low level operation. so its different from a normal full OS.
This problem of bad cables caused me a lot of lost time in asking my self, "Oh Why is it not working!" It was only when someone on the IRC help channel encouraged me to try a different usb cable i found that was the problem.
idk the details of reflashing bootloader but i guess its more sensitive/less or no error correction, hence the problem. i had not noticed previous use of the bad cables being a problem with day to day use.
Note that reflashing bootloader was a low level operation. so its different from a normal full OS.
This problem of bad cables caused me a lot of lost time in asking my self, "Oh Why is it not working!" It was only when someone on the IRC help channel encouraged me to try a different usb cable i found that was the problem.
Last edited:
LOL. That's one of the laziest cop-outs I've ever seen. You started this whole mess, and now you leave. Was your plan just to stir the pot then leave when it got to hot for you? Scottmoose sums it up perfectly above.
Well at least we can hope some people learned a little about how digital interconnects work - and don't work.
- Status
- Not open for further replies.