4 ms·

>Yeah, right. If you get "smeared" digital signals beyond the sampling threshold, you'll get so many data errors that nothing will work. I don't want to feed t

>Yeah, right. If you get "smeared" digital signals beyond the sampling threshold, you'll get so many data errors that nothing will work. I don't want to feed the audiophile nonsense but you do get high frequency attenuation with shitty cables and human hearing is pretty dang sensitive. Even just slight attenuation can and will incur jitter in the signal. It's just that one can mitigate the damage it with some clever circuitry and using anything other than coathangers or wet string... Also come on, our sense of hearing is likely much more capable than our sight. If you introduce things like delta-sigma modulation, the jitter requirements become pretty ridiculous too. Something on the order of two digit picoseconds RMS. It's cool to hate on ridiculous 1000 dollar HDMI cables and monster sized mains power cables but legit audio engineering can be pretty challenging, since our sense of hearing is actually way more sensitive than most other things we encounter.

ohazi 7y ago
The reason the "smearing" argument doesn't hold water when looking at jitter from something like a USB cable is that this interface is being used to send a bitstream, not timing information (at least not directly). The way it usually works is that first the computer sends some sort of mode-setting message. This is where the computer tells the Audio DAC controller what output sampling rate to use. The DAC then uses its own internal circuitry to generate the timing signals. This circuitry is what determines the jitter. The computer then sends the audio data over the cable. This data is captured, buffered, and then finally sent to the DAC when the internally generated timing system is ready for it. So the only thing that cable smearing can do is introduce errors into the digital messages that the computer sends. If it's particularly bad, the mode-setting message won't make it intact and you won't hear anything. If the mode does get set correctly, but there are occasional bit errors in the bitstream, you'll hear occasional (but obvious) pops. If the computer can't send the bitstream at the expected rate, the buffers will over or underrun and everything will stop. But what you won't get is more jitter. The original argument assumes that the cable is sending a signal whose edges are used for clock recovery, and that this recovered clock is used as the timebase for the sampling system. But nobody actually does this [1]. Reasonably high jitter / phase noise on the bitstream signals is fine, as long as the data can still be decoded. [1] Okay fine, HDMI sort of does this, but they're almost always using a more sophisticated retiming system.
- hatsunearu 7y ago
  OK yeah, I'm not sure what I was thinking when I wrote about cabling. I agree that clock recovery and PLL filtering can take care of jitter.
deleted 7y ago
[deleted]

ohazi 7y ago

The reason the "smearing" argument doesn't hold water when looking at jitter from something like a USB cable is that this interface is being used to send a bitstream, not timing information (at least not directly). The way it usually works is that first the computer sends some sort of mode-setting message. This is where the computer tells the Audio DAC controller what output sampling rate to use. The DAC then uses its own internal circuitry to generate the timing signals. This circuitry is what determines the jitter. The computer then sends the audio data over the cable. This data is captured, buffered, and then finally sent to the DAC when the internally generated timing system is ready for it. So the only thing that cable smearing can do is introduce errors into the digital messages that the computer sends. If it's particularly bad, the mode-setting message won't make it intact and you won't hear anything. If the mode does get set correctly, but there are occasional bit errors in the bitstream, you'll hear occasional (but obvious) pops. If the computer can't send the bitstream at the expected rate, the buffers will over or underrun and everything will stop. But what you won't get is more jitter. The original argument assumes that the cable is sending a signal whose edges are used for clock recovery, and that this recovered clock is used as the timebase for the sampling system. But nobody actually does this [1]. Reasonably high jitter / phase noise on the bitstream signals is fine, as long as the data can still be decoded. [1] Okay fine, HDMI sort of does this, but they're almost always using a more sophisticated retiming system.

hatsunearu 7y ago
OK yeah, I'm not sure what I was thinking when I wrote about cabling. I agree that clock recovery and PLL filtering can take care of jitter.

deleted 7y ago

[deleted]