"Cables can “smear” digital signals by attenuating the highest frequencies."
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])
>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.
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.
For a real laugh you can go look around for gold plated toslink cables. There's at least a dozen brands out there. Somehow I doubt gold plating optical cables will improve signal quality...
They sure seem to imply it improves things in the product descriptions though. I just found it interesting how that trick works even for selling non-electric interconnects.
I mean for certain things making whatever its plating not rust is a nice thing. For electrical connections that's a great idea; for other things it might be for looks.
NwAvGuy was a true beacon of light in the sea of bullshit that the audiophile community can sometimes be. It's sad he's not around anymore. I had a lot of fun building his Objective2 amplifier.
I bought the assembled O2/ODAC from JDS labs, and then the black edition a few years later. It's essentially a perfect product and I fully believe that any claims of superior transparency in audio reproduction over it from any other manufacturer are 'outside the realm of human perception' (i.e. snake oil).
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.
It's true. One of the few blogs I've read from end to end. In fact I've even scraped it and keep it saved just to make sure that nothing ever happens to it. I own his DAC design, which is great as well.
It’s true that audiophiles can be some of the worst pseudoscientists around. But still, without the input of some good journalists (like NwAvGuy) I honestly wouldn‘t have found the bliss that is a good-quality and nicely set-up stereo system. I find that this topic is gettig far too little attention compared to visual media (4k, 8k, etc)
So the article is in reference to audio... Jitter in regards to sending data/requests to a 3rd party, such as a cloud provider of a service... definitely a good thing.. it helps differentiate your requests from a DDOS.
Skimmed the article to see the subject, saw it was audio, but still wanted to make this comment.
Jitter is always introduced by non-RTOS operating systems that don't have a guarantee for preemptive realtime scheduling. The kernel scheduler introduces jitter, supervisory processes introduce jitter, etc. And an easy test to see the effects of this is to try to control a servo motor with a GPIO pin without RT_PREEMPT or comparable RTOS.
Simple fix would be an RT_PREEMPT-linked Linux sound player.
Scheduling jitter does not cause jitter in audio, because audio is buffered and the buffer is consumed by audio device using it's own clock. Yet OS has to fill the buffer in time or underrun will happen, which will be audible as crackling and stutter. For some applications input and output audio buffers need to be very small to avoid introducing noticeable delay in audio processing, and in this case real-time capabilities are required to prevent buffer overruns and underruns.
Jitter was a HUGE issue in ~2004 for Lucas/ILM wrt rendering speeds... but due to how long ago that was, I dont exactly recall why...
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...
"Cables can “smear” digital signals by attenuating the highest frequencies."
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...
>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.
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.
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.
For a real laugh you can go look around for gold plated toslink cables. There's at least a dozen brands out there. Somehow I doubt gold plating optical cables will improve signal quality...
I mean, you can file that one under "looks cool". Absolutely doesn't improve anything else though.
They sure seem to imply it improves things in the product descriptions though. I just found it interesting how that trick works even for selling non-electric interconnects.
I mean for certain things making whatever its plating not rust is a nice thing. For electrical connections that's a great idea; for other things it might be for looks.
Looks is important, and I'm not being ironic.
NwAvGuy was a true beacon of light in the sea of bullshit that the audiophile community can sometimes be. It's sad he's not around anymore. I had a lot of fun building his Objective2 amplifier.
I bought the assembled O2/ODAC from JDS labs, and then the black edition a few years later. It's essentially a perfect product and I fully believe that any claims of superior transparency in audio reproduction over it from any other manufacturer are 'outside the realm of human perception' (i.e. snake oil).
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.
It's true. One of the few blogs I've read from end to end. In fact I've even scraped it and keep it saved just to make sure that nothing ever happens to it. I own his DAC design, which is great as well.
It’s true that audiophiles can be some of the worst pseudoscientists around. But still, without the input of some good journalists (like NwAvGuy) I honestly wouldn‘t have found the bliss that is a good-quality and nicely set-up stereo system. I find that this topic is gettig far too little attention compared to visual media (4k, 8k, etc)
So the article is in reference to audio... Jitter in regards to sending data/requests to a 3rd party, such as a cloud provider of a service... definitely a good thing.. it helps differentiate your requests from a DDOS.
Skimmed the article to see the subject, saw it was audio, but still wanted to make this comment.
Jitter is always introduced by non-RTOS operating systems that don't have a guarantee for preemptive realtime scheduling. The kernel scheduler introduces jitter, supervisory processes introduce jitter, etc. And an easy test to see the effects of this is to try to control a servo motor with a GPIO pin without RT_PREEMPT or comparable RTOS.
Simple fix would be an RT_PREEMPT-linked Linux sound player.
Scheduling jitter does not cause jitter in audio, because audio is buffered and the buffer is consumed by audio device using it's own clock. Yet OS has to fill the buffer in time or underrun will happen, which will be audible as crackling and stutter. For some applications input and output audio buffers need to be very small to avoid introducing noticeable delay in audio processing, and in this case real-time capabilities are required to prevent buffer overruns and underruns.
Jitter was a HUGE issue in ~2004 for Lucas/ILM wrt rendering speeds... but due to how long ago that was, I dont exactly recall why...
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...
It does for realtime. This article only cares for audio, but with realtime jitter is the worst problem of all.
Comparable to memory failures, segv, out of bounds, ... Usually caused by a HW problem, but sometimes SW is at fault also.
Love NwAvGuy’s DAC and amp. I own two of each and attempted to upgrade to expensive alternatives only to be disappointed.