Jitter – Does It Matter? (2011)
nwavguy.blogspot.com
nwavguy.blogspot.com
Yeah, right. If you get "smeared" digital signals beyond the sampling threshold, you'll get so many data errors that nothing will work.
The only thing that matters is whether whatever is clocking the DAC has a constant clock rate and that you don't get a buffer underrun on whatever feeds it data.
If this were a real problem, it would have shown up on analog VGA monitors as a wobbly image. Those are also an analog signal from a DAC coming from a clocked data stream. Several orders of magnitude faster than for audio. There have been VGA devices with jitter problems, and it's really obvious - vertical lines aren't straight. That was pretty much fixed by the time VGA went away.
(There was once a $13,500 HDMI cable. Really[1]. It was laughed at on Amazon.[2])
[1] https://www.forbes.com/sites/ianmorris/2015/01/02/please-don...
[2] https://www.amazon.com/WireWorld-Platinum-Starlight-Cable-Me...
Looks is important, and I'm not being ironic.
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.
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.
I agree that clock recovery and PLL filtering can take care of jitter.
There might be a few nice utility bells and whistles on other products but that's it.
Probably someone in the industry made him a hush money deal he couldn't refuse and that was that. Good for him.
Skimmed the article to see the subject, saw it was audio, but still wanted to make this comment.
Simple fix would be an RT_PREEMPT-linked Linux sound player.
They were the first Foundry customer, for these reasons...
They had render farms that were sensitive to jitter... Raleigh Mann later went on to run netops for google... thought he has left there and now runs williams sonoma - but he was super jitter allergic...
Comparable to memory failures, segv, out of bounds, ... Usually caused by a HW problem, but sometimes SW is at fault also.