I address the issue of audibility, or better said, inaudibility, in the second part of my latest article in WSR. Here is an online copy: http://www.**************.com/Library/AudibilityofSmallDistortions.html
As to signals being digital and therefore it doesn't matter, I addressed that already in my previous article. If someone wants to keep arguing, then maybe they can explain why jitter over HDMI can be 10X higher than jitter over S/PDIF *in the exact same AVR*. Both of these inputs are ostensibly "digital." Yet there are these measured differences all the way through the AVR at its analog outputs. The answer is that digital audio is not digital. It conveys digital samples and analog timing data. So you can argue all day long about the digital part but you can't do anything about the analog.
As to this statement by Arny: "If you want to talk about digital audio signals that have massive timing errors as received, consider the packets of data that are routinely received when movies and music are downloaded, particularly streaming media. The nature of the TCP/IP data transfer process that is universally used is that data packets may be received out of order, via different paths, and with random and large timing errors. Yet, we receive these movies and they sound great!"
This is a totally different architecture and the way it should have been for our consumer devices but isn't. Computer guys did not design S/PDIF or we would not have the issues that we have. The architecture in streaming environment is such that the audio device/DAC is the master. It demands audio from layers up stream to it. To keep up with it, the layers above maintain what is called a "leaky bucket" where they try to keep a buffer with enough data as to make sure the audio device/DAC does not run dry. The "buffering" message you see at the start of say, Youtube video, is for this. The buffer allows the upstream data to be non-real-time and very jittery. While the data out of the buffer to the DAC remains real-time and with high precision. Variations in the timing of source data is not a factor since the output device has its own source of timing.
It is of course possible for the above system to break down. If you can't feed the buffer fast enough, playback will by definition stop as you run out of data to play. I am sure you have seen this where you video stops playing and you get the dreaded "buffering" message. Have you ever seen that happen with your CD player? Nope. Why? Because it doesn't work this way (see below).
You can also get packets out of order over the Internet. If the out of packet data arrives in time for the audio device/DAC to play them, they they will be used. Otherwise, it is too late and we throw them away. The result is an audible mute, glitch, or pop because we don't have the samples to play. Again, have you see your CD player do that mid-span of playing some content? Nope. Why? Because it doesn't work that way.
The architecture of our home consumer systems is one where the source is the master, not the DAC/receiver. The source shoves down the bits into the throat of the receiver whether it wants it that fast or not. The receiver can't therefore decide to use its own (high precision) clock and run at its own pace like we did in the streaming case above. The receiver needs to instead "lock" to the rate of incoming bits. If those bits change in timing, the receiver will track some of that change as that is what it is supposed to do (figure out the rate of incoming data). Since all transmission lines suffer from such timing errors, then by definition we let some amount of distortion through. Unfortunately, as I explained in the above article, the threshold of audibility for timing errors can be surprisingly low.
There are fixes to this problem such as using asynchronous USB which transforms the system to work like the streaming case bove. Or as OP has done, use a different input with less jitter. So this doesn't have to cost money. There are also better and worse implementations.
You can also pretend the problem is always inaudible which is also fine. Just don't say it is so because you post a block diagram and say the circuits are the same. Or bring analogies like streaming which do not at all work the same way as this system. We either care about how these systems work or dont'.....