Bogus claims Re: OTB summing from Black Lion

[Snarl 12/8]

Apparently there is such a thing as a DSP clock.

http://www.springerlink.com/content/m453625099413v34/

Protools can even throw a DSP clock error....
http://duc.avid.com/showthread.php?t=57809

I don't know what it does, but I would assume that errors in its function could cause errors in the resultant output any processing that may rely on it.

[wesley.wittich]

Apparently there is such a thing as a DSP clock.

http://www.springerlink.com/content/m453625099413v34/

Protools can even throw a DSP clock error....
http://duc.avid.com/showthread.php?t=57809

I don't know what it does, but I would assume that errors in its function could cause errors in the resultant output any processing that may rely on it.

Even if there are DSP clocking errors, how would these be avoided by summing OTB? The audio would still be played back by a computer, and in many situations the stereo mix would be put back into PT or something...I don't understand how OTB summing avoids computer clock based issues.

[Snarl 12/8]

Apparently there is such a thing as a DSP clock.

http://www.springerlink.com/content/m453625099413v34/

Protools can even throw a DSP clock error....
http://duc.avid.com/showthread.php?t=57809

I don't know what it does, but I would assume that errors in its function could cause errors in the resultant output any processing that may rely on it.

Even if there are DSP clocking errors, how would these be avoided by summing OTB? The audio would still be played back by a computer, and in many situations the stereo mix would be put back into PT or something...I don't understand how OTB summing avoids computer clock based issues.

Just playing devil's advocate...
If you go OTB you're not doing DSP (processing) just converting. So, you'd avoid DSP errors in favor of getting converter clock errors. Maybe this is one of the main reasons, in BLA's 'mind', that the two processes sound "different." It also seems to me that there are more options for improving your converter clock vs. your DSP clock, which, on native systems is probably something of dubious quality tied to your cpu.

[KennyLusk]

Very interesting page of information here.
http://www.bores.com/courses/intro/basics/1_quant.htm

Going back to what I posted earlier with regard to overclocking the cpu chip...AMD chips, etc....math co-processors being of greater quality in AMD chips vs. Intel chips were for quite some time a deciding factor when choosing between AMD or Intel cpu chips. For me, this is still a reason today I stick with AMD chips. DSP clocking an issue? Math co-processors an issue? FPU blah blah blah? Yes. Used to drive me crazy sometimes when computer/communications tech troubleshooting was my day gig. Happily, I no longer do that for a living.

[leigh]

If you go OTB you're not doing DSP (processing) just converting. So, you'd avoid DSP errors in favor of getting converter clock errors.

Even if summing OTB, 99.9% (just a rough guess) of users are still using DSP. Any type of change to the input signal once it's in the computer requires DSP. This includes:

Volume changes (having your virtual mixer's channel faders at anything but unity)
Plug-in processing (of course)
Sub-mixing (since most summing boxes handle only 8 or 16 channels of summing, and often users have more tracks than that, they must submix some of the tracks before sending them out of the box)

So summing OTB does not evade DSP (unless you are mixing on a console, and using your computer strictly as a tape recorder).

[KennyLusk]

When summing ITB you're putting a heavier load on the computers internal DSP clock when you consider processing x-number of instances of plug-ins on your channels, aux busses, and main busses. When summing OTB everything is Real Time and there is "potentially" a relatively lower load (or potentially lesser chance of bottlenecking errors) on internal processing when you're asking your box to simply convert a 2 channel incoming analog signal to a single stereo event. Seems to me like that's what they're saying. And personally I would agree with that FWIW.

Something to point out though is many here have been arguing that internal DSP clock errors are a fallacy. Rendering BLA's claims to be "misleading". Once you admit that there is indeed such a thing as internal DSP clock errors then I think this discussion is concluded.

[Scodiddly]

I'll say it yet again, once again in slightly different terms so maybe more people will finally get it:

Math done in computers is not something that has vague results or is easily influenced by subtle outside factors. Either the bit is set, or it's not set. There are hard tests that can verify this, and the companies that make the chips use these tests as part of quality control. The software that runs on the chips also includes some self-checking.

[leigh]

When summing ITB you're putting a heavier load on the computers internal DSP clock

A clock does not get "loaded" down, based on how many calculations the processor it is clocking is performing. That's just not how computers work.

when you consider processing x-number of instances of plug-ins on your channels, aux busses, and main busses.

If all you're doing OTB is the summing step, then all those plug-ins you're talking about are still going on ITB.

For example, suppose you're using an 8-channel summing box like, say, the Black Lion PM8. In terms of reducing your computer's processor load, how might that help? It means roughly: 7 fewer addition operations per sample, and maybe one less multiplication operation per sample (for scaling the summed signal in the digital mixer), or perhaps eight fewer multiplication operations per sample if the signals are scaled first before summing.

That's an approximate explanation, sure - but for an 8 channel summing box, we're talking about reducing processor load by a handful of calculations per sample. Next to dozens of plug-ins emulating vintage compressors, CPU-hungry convolution reverbs, and component-modeling guitar amp sims, those few extra calculations are a drop in the digital bucket.

In other words, not asking your computer to sum those last 8 channels has a negligible effect on processor load.

When summing OTB everything is Real Time and there is "potentially" a relatively lower load (or potentially lesser chance of bottlenecking errors) on internal processing when you're asking your box to simply convert a 2 channel incoming analog signal to a single stereo event.

Why would performing something in Real Time have a lower processor load? Wouldn't operating in non-Real-Time allow the processor more breathing room, as it were?

Something to point out though is many here have been arguing that internal DSP clock errors are a fallacy. Rendering BLA's claims to be "misleading". Once you admit that there is indeed such a thing as internal DSP clock errors then I think this discussion is concluded.

Sure. I haven't admitted that, however. A more heavily-loaded processor does not start creating little errors. It either is able to keep up with what you've asked it to do, or it stops and says it can't keep up. (^^ What Scodiddly said...)

Leigh

[KennyLusk]

So then, you guys are back to saying there's no such thing as DSP clock error's?

[The Scum]

Give me a good, hard definition of "DSP clock error" and I'll get back to you. That's one of the issues being debated here.

BLA make it sound like jitter in the DSP instruction execution clocking (which may well exist) somehow causes errors in the math being performed, or creates undesirable audible artifacts.

If so, I'd expect a number of AES Journal articles covering it in extreme detail...just like sample clock jitter has been hyper-analyzed through the years.

In other words, not asking your computer to sum those last 8 channels has a negligible effect on processor load.

Agreed. And, in fact, if you're using a bunch of outputs simultaneously, it introduces more work that goes into feeding samples to the driver...interrupt handling for output buffer streaming...which raises the amount of real time work being done. Not that any reasonable system isn't perfectly capable of handling that load - though if you start opening ASIO outputs in your DAW, you can watch the CPU usage & bus bandwidth increase.

[Scodiddly]

So then, you guys are back to saying there's no such thing as DSP clock error's?

I've never said there are "DSP clock errors". I think it's a made-up problem that doesn't exist.

ITB and OTB summing would likely sound different, though. The extra DA-AD conversions alone in OTB will change the sound, plus probably some more change from the summing circuitry. The only question here is whether you like what OTB does to the sound, and that's part of the art of audio instead of the science.

Science is here to support the art. Art should just be about honestly deciding what you like. The problem is that bad science is used to sell products to artists.

[Jim Williams]

"doesn't play well with others" ?

[KennyLusk]

BLA make it sound like jitter in the DSP instruction execution clocking (which may well exist) somehow causes errors in the math being performed, or creates undesirable audible artifacts.

If so, I'd expect a number of AES Journal articles covering it in extreme detail...just like sample clock jitter has been hyper-analyzed through the years.

I don't know what articles are on file at AES, I'm not a member. But errors in the math being performed in any computer can exist and can create undesirable artifacts in audio [or] video. This is a known factor and always has been.

More simple reading material:
http://en.wikipedia.org/wiki/Truncation_error
http://en.wikipedia.org/wiki/Round-off_error
http://en.wikipedia.org/wiki/Aliasing

For 10 years 5 days a week I troubleshot other peoples computers and became very familiar with different levels of affect these kinds of errors can have with regard to integrated and peripheral devices used in processing audio and/or video. Some of these problems were show-stoppers and some were not. It also helps to know a little about tcp/ip which isn't easy for everyone to grasp and of course most people have never even cracked a book about tcp/ip much less sat in classes covering the subject.

Again, computers make mistakes when processing mathematical calculations. It's that simple.

Here's a little sample statement from a source that talks about the C5510 DSP kit (from Texas Instruments) and some of the inherent problems that can occur in "throughput" with Real Time Data Exchange:

"And for C5510 whose clock signal changes with CPU clock, then once the CPU clock changes, either due to change in internal PLL or external oscillator, all timing functions needs to be updated to accord with the new clock cycle period. This made programming harder and more prone to clock cycle period counting error."

This stuff isn't made up, it's real. The OP's opening statement and reason for posting this thread was "ITB summing is, in fact, not prone to clock based errors"...his words. When actually any ITB mathematical calculations can be vulnerable to errors, as as illustrated above, can be prone to clock-based errors.

I hope Jim's remark wasn't directed toward me specifically because I feel like I'm "playing" very nice to be honest. Just participating in the discussion, not being rude in any way. Everything I've said has been pretty straight forward.

[leigh]

I don't know what articles are on file at AES, I'm not a member. But errors in the math being performed in any computer can exist and can create undesirable artifacts in audio [or] video. This is a known factor and always has been.

...This stuff isn't made up, it's real. The OP's opening statement and reason for posting this thread was "ITB summing is, in fact, not prone to clock based errors"...his words. When actually any ITB mathematical calculations can be vulnerable to errors, as as illustrated above, can be prone to clock-based errors.

The types of errors you list are mathematical errors (such as rounding and truncation). Those errors can be present on any computer using a finite number of bits... and I have acknowledged them all along. They are not clocking errors.

The Texas Instrument example you posted about their DSP kit says that needing to update certain timing functions made "programming harder". I think it has been an assumption here all along that, when we're talking about DSP summing being error-free, we have been talking about a properly-programmed system. So the fact that a poorly-programmed system could exhibit timing errors doesn't prove anything. That would be like saying "transformers sound like crap", just because you could point to some cheap transformers with massive low-end rolloff.

Leigh

[jhharvest]

Furthermore, the TI chip in question here is a general purpose DSP chip and works with clock frequencies of 200MHz, which is several orders of magnitude higher than anything happening in our audio domain. The clocking issues there are completely different than any word clock issues.

As an aside, I was going to suggest a very easy method of testing this whole issue. The method is to bounce the same session ITB several times, then compare the resulting audio files bitwise. If the files are identical we can pretty much rule out any clocking issues.

However! I did try this already, using Harrison Mixbus with a session I did recently. And turns out in average approximately 10% of the words differ by a byte. Cue my surprised expression. How can this be! Well, it's pretty obvious. One of Harrison's selling points is fixing the "lacking dither stages in the DSP processing". That there is dither noise. The difference averages at -120dB at approx. 10% of the words, as you would pretty much expect.

But identical the files are not, so the jury is still out on this one. So I'll redo the testing once I'm at my Protools rig (the presumable culprit of the lacking dithering) and post back with the results.