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

[Dylan16807]

Yes, sure, those things are hard, and they have nothing whatsoever to do with the quality of passive components like cables, as long as they are not in the failure range. Or anything to do with working-transceiver quality except when it comes to the clocks that the transceivers are using.

When you talk about jitter introducing significant distortion based on packet timing, that's something that can only happen in two ways: either the audio receiver is using an absolute garbage clock, or it's using an absolute garbage and shortsighted algorithm for adjusting its clock rate, and not trying for a stable sync. The quality of transceiver and cable components is not a factor.