[rdale]

In over 100 audiophile bashing posts, at last someone who actually understands the issues. USB cables have an 'eye pattern' which affects the timing of the signal presented to the DAC.

If USB cables make a difference, then there is probably an argument for doing something else (not ignoring the problem because USB cables must be 'perfect'). Like putting the DAC and computer driving the DAC in the same box and connected by I2S with the DAC as the master.

There are some good articles on the Audiostream site about why 'bit perfect' doesn't cut it in the context of audio:

http://www.audiostream.com/category/industry-voice

[Dylan16807]

What kind of insane hardware depends on CPU timings and doesn't have a hardware buffer that always plays at the same speed? Jitter in the intermediate steps doesn't matter when you're moving digital data from one place to another, as long as the buffers are larger than the amount of jitter.

DAC is hard. Moving a couple megabits of data five feet over a cable with multi-millisecond buffers is not hard.

I don't think it's even possible to use USB for 100%-throughput unbuffered data. I call bullshit on the eye pattern affecting playback.

Just because a difference technically exists in some circumstances with an oscilloscope does not mean it makes a difference in normal use cases.

Also wow that site called wireless a 'potential long-term health risk'.

[rayiner]

What you're describing isn't as easy as it sounds. In order to have a "hardware buffer that always plays at the same speed" you need a high-quality locally generated clock, plus a decent amount of local buffering. But in a USB audio device or SPDIF device, you can't run a totally independent clock, because it will get out of sync with the clock on the host device sending the data. There are various tricks to get around this (e.g. having a feedback loop using a sideband), but it's actually a non-trivial problem. See: http://www.cypress.com/?docID=45044 for one approach. Most USB audio devices don't even attempt to do this. They try and recover the host machine's playback clock using the timing of USB SOF packets (which are sent every millisecond-ish) plus the timing of the USB audio data packets it receives.