Scodiddly wrote:"DSP clock" affects calculations? Man, that sure smells funny. If I get a better clock will my spreadsheets be more accurate? Will my tax returns have a bigger refund?
Yeah, it does smell funny.
I'm debating whether to share the entirety of my discussion with "BLA" here. First I would like to at least make sure he and I are on the same page, and I'm trying to reach some kind of conclusion to our dialog. But for those of you dying to know more, here's the first part of his response.
I had sent him a slightly edited version of my original post in this thread. To recap, my first assertion was that "The process of summing ITB is, in fact,
not prone to clock-based errors - because there is no clocking going on!"
His response:
First, the summing done in the digital domain requires the use of DSP. As you may know, DSP processes are not conducted in a vacuum, and they are not all the same. They are subject to real-world limitations, such as DSP math processes, logic switching and current movements, gate input capacitances, cross-talk related anomalies, resonant poles on the supply line, etc. When we say "clock-based errors," we are not referring sample or master clock signals, we are talking about issues created within DSP by logic switching noise, eye pattern errors, cross-talk issues, and other real-world imperfections that manifest themselves in our otherwise simple and ideal "sum all samples at a time" scenario.
I dunno, what do you make of that?
I should mention that I do agree that "DSP math processes" are one of the limitations of digital summing. The math is carried out with a finite number of bits, and at some point you're probably scaling down the signal (reducing gain). This reduction (via multiplication) results in a tiny rounding error. These errors can be cumulative and, in theory, audible - but on a well-designed 24-bit system it's not a big issue.
Other than that one point, the rest makes my brain hurt.
Leigh