PlanetZ forums - scopeusers.com

On 2006-01-20 14:03, braincell wrote:
USB and Firewire suffer from Jitters.

I don't think you quite understand jitter and its implications - but firewire/USB audio cards do not suffer from jitter by virtue of being firewire/usb. If an audio device has a good clock then doesn't matter whether it is firewire/usb/PCI.

Yet it's in the very nature of that type of math that only a few iterations with a very, very tiny error lead to almost random results.

Imho that's the reason why a 'specialized' DSP math (as provided by Analog Devices in our case) will ALWAYS yield better results than a general purpose PC lib.

This is far from a 'defensive position' regarding literally outdated gear - any native plugin POTENTIONALLY could sound identical to it's Scope counterpart (if played back via the same converter)
... if the same quality of math implementation would exist in a X86/87 library, which obviously isn't the case.

This isn't true. Floating point implementation is a well defined IEEE standard that intel processors certainly DO adhere to. Floating point maths on a CPU is just as good as it is on a DSP.

Well the big problem with USB and Firewire is that, as SFP and subsequent plugs have been designed to use the system memory of the host computer, you need to have a really fast and wide path through the system bus.

Many of us who have played with using the Magma chassis to make our CWA systems portable have come to discover that even using the included high-speed SCSI cable (@133MB/sec), information which is being processed in real-time can't compute in time due to a system traffic jam. The SHARC DSPs, while amazing in their own right, are designed to run in real-time, unlike our host processors. If a process takes to long, SFP essentially craps the bed. Goodnight Gracie.

In order to be able to use a CWA system over such a narrow and slow bus (remember 480Mbits means... 8 bits to a byte, 480/8 = 60MB/sec burst speed, not sustained. Not so fast is it?) you'd have to not only throw a whole mess of memory on each board, or use SHARCS with a nice amount of RAM per SHARC, but you'd have to rewrite ALL the software which uses the system memory to use the on-board memory. Hint: most plugs access the system memory for SOMETHING.

Not only that, but if you prevent access to system memory, then you're forced to sacrifice some of your overall SHARC resources to running SFP as they did for NOAH.

Having said that, if they DO find away to handle all the work involved in re-designing all of that stuff, my vote is for FireWire 800, as you'd essentially 1.5x the amount of tracks you can push in each direction and will maintain better sustained speeds than USB2.

On 2006-01-21 07:19, stardust wrote:
I checked steinberg's website.
There is no Cubase 64 bit announced.

Yep, what was released was only the VST 2.4 SDK and specifications -- which as far as I can see, only adds a function to be called when running in 64bit mode (processDoubleReplacing()) instead of the standard 32bit processReplacing() --, and not an actual 64bit Cubase (although I'm sure they're working on that too.)

On 2006-01-28 10:20, thomashenrydavies wrote:

...a 'specialized' DSP math (as provided by Analog Devices in our case) will ALWAYS yield better results than a general purpose PC lib.
... any native plugin POTENTIONALLY could sound identical to it's Scope counterpart
... if the same quality of math implementation would exist in a X86/87 library, which obviously isn't the case.

This isn't true. Floating point implementation is a well defined IEEE standard that intel processors certainly DO adhere to. Floating point maths on a CPU is just as good as it is on a DSP.

WHAT isn't true ?
Didn't my quote above explicetely include that a CPU based plugin could sound as good (or bad) as one based on DSP code ?

Would you expect better audio processing from a general purpose chip supplier than from a specialist who (literally) releases millions of high end consumer devices per year ?

Quadratic equations ARE an important part of DSP math and (as mentioned) there's no fundamental difference between a $10 pocket calculator and a $10 million supercomputer in this context - ANY system with a finite number of digits WILL fail precisionwise.

it is completely irrelevant if a SINGLE math operation is defined correctly (according to whatever standards).
This is about iterated functions, about looped code, and even the choice in which form the algorithm is represented has an influence on the result (as mentioned).

Since errors are unavoidable anyway, I simply assume that the 'specialists' will find ways to control the direction in which the result developes, while the 'standard version' will just run out of control. But of course that's speculative...
Regarding the Sharc libraries (afaik) these are not pure math operations, but also include basic building blocks for functional processing (like a filter for example).

Not that I want to make too much publicity for 'Chaos and Fractales', but the chapter quoted (on the previous page) should at least be read once by anyone who's interested in this type of programming

cheers, Tom

<font size=-1>[ This Message was edited by: astroman on 2006-01-28 16:09 ]</font>

I can't claim to have a proper understanding of the subject, but I was under the impression that integer-based maths like that used by DSP cards like Scope and Pro Tools TDM is not prone to inaccuracy like floating point maths (i.e. no rounding issues)?

that was the reason to quote the book - it's easily accessible in any 'better' bookstore and a quick browse of that chapter gives a good impression of what's going on.

We use to believe in the precision of math on computers, as billion $ balances are calculated every day, but that may leave a 'false safety' impression.

I don't even think that it's a question of integer versus floating point precision.
If any then it's a question of well thought out processing instead of careless formula translation.

Intel's isn't even in charge in this case as application developement isn't their cup of tea.

cheers, Tom

On 2006-01-28 17:04, darkrezin wrote:
I can't claim to have a proper understanding of the subject, but I was under the impression that integer-based maths like that used by DSP cards like Scope and Pro Tools TDM is not prone to inaccuracy like floating point maths (i.e. no rounding issues)?

Sharc DSPs are floating point ones, not fixed point.

Are you sure? I'm pretty sure the ones used in Scope cards are 32-bit integer, although Analog Devices might have floating point ones in their range of products too.

<font size=-1>[ This Message was edited by: darkrezin on 2006-01-29 09:24 ]</font>

Sharcs can definetely do integer AND floating point math - whatever you like

I don't quiet see the interest of 64 bit which would be 96Khz at 24 bit, 192KHz at 32 bit and 64 bit would be around...calculates...576Khz So I might as well start composing for Dogs,Rabbits and Woodland animals.

Mm H-Rave, bitdepth and sampling rate are unrelated to each other. You can have 8bit 192KHz, 1bit 2.8224MHz (this is what DSD/SACD uses), and so on. Bitdepth affects dynamic range (i.e. what's the smallest amplitude difference you can encode), while sampling rate affects the frequency bandwidth you can encode (i.e. what's the highest frequency you can encode and reproduce correctly.)

Mmmm.... yes I see.