How Long B4 CPU's Catch Up To DSP?

dawman · Post by **dawman** » Mon Jun 12, 2006 1:54 am

With Intels anouncement of Quad Core CPU's on the horizon, how will this affect native recording apps.? Do we as a platform, still have a viable future 4 years 2 come? Will CW hail Anna Luse as a hero with record sales of ASB's and babes?

Shroomz~> · Post by **Shroomz~>** » Mon Jun 12, 2006 2:03 am

Do you really care?

dawman · Post by **dawman** » Mon Jun 12, 2006 2:13 am

Yes, that's why I'm building a 2nd DAW with EnergyXT as a reserve. I don't want to be the last one standing when the music stops, and this will give me more versaltility in respect to recording applications. But I still feel that 32bit integer recording is better in mastering, and summing at this time, but feel as though native recording apps are multithread, and will continue to upgrade all the way to 64bit, leaving VDAT behind. I have read that 48bit integer is the future in recording apps. So put that in your pipe and smoke it.

Shroomz~> · Post by **Shroomz~>** » Mon Jun 12, 2006 2:15 am

Don't own a pipe mate, but nice offer anyway, thanks.

dawman · Post by **dawman** » Mon Jun 12, 2006 2:26 am

You could mix it with some shroomz in a blender, and mix it with Russian Vodka/Orange Juice to cover the Psycillasciben taste of the shroomz.

astroman · Post by **astroman** » Mon Jun 12, 2006 2:28 am

the answer is simple never

it doesn't mean it's impossible (in technical terms), but since it didn't happen the last (say) 5 years why should it be happening during the next half decade ?

developement on DSPs doesn't stand still just because it's not covered in mass press.
in fact all those every day life 'conveniences' we got so used to, like cell phones, satellite TV, dsl lines on copper, density of harddisk storage etc are all dsp achievements, some even SHARC based.

for every DSP sold to CWA, Analog sells at least 10k to makers of communication gear and 5k units to the medical market - and then all this 'intelligent ammo'... that's supplies us with funky images of destruction in the news.
A WinCE driven war head would probably be more frightening than the worst enemy

then you simply don't find all the benchmarked CPU power back in real world applications.
Except for a (very) few highly specialized routines I'd estimate a current CPU is used between 5-10% of it's capabilities - extrapolating from what I've experienced since the mid 80s.

a lot of the performance advantages are simply based on faster storage, not processing - the original Mac had an 8 MHZ 'bus', so to say...

cheers, tom

[ This Message was edited by: astroman on 2006-06-12 03:31 ]

dawman · Post by **dawman** » Mon Jun 12, 2006 2:34 am

I am relieved by your information Brotha'Man Astro. Microsoft has scared me with their never ending upgrade paths, as everyone seems to follow.

darkrezin · Post by **darkrezin** » Mon Jun 12, 2006 4:04 am

The new CPU's will give more power, but when it comes to audio stuff it will never be as good as DSP, because it will always be buffer-based (maybe this will change when true real-time operating systems exist for mass markets?).

Buffer-based processing is not as responsive as sample-by-sample realtime DSP and never will be.

However, with the raw grunt of more powerful CPUs, much better native synthesis algorithms will become possible.

Personally, I use VST's, Scope and (mostly) hardware. Whatever gets the job done at any one time, in any combination. I don't see the point in limiting yourself to any one platform/format.

[ This Message was edited by: darkrezin on 2006-06-12 05:05 ]

astroman · Post by **astroman** » Mon Jun 12, 2006 5:18 am

On 2006-06-12 05:04, darkrezin wrote:
...However, with the raw grunt of more powerful CPUs, much better native synthesis algorithms will become possible...

it has been possible at any moment in time

but if I remember correctly the very first version of Reaktor I tried had the exact same soundprint than their latest demo - and my CPU was a Celeron 333 those days.

Obviously NI didn't care much about algorithms and 'possibilities' - it's all one engine, regardless if Reaktor, FM7, B4, GuitarRig etc - the noiseprint is clearly detectable.

Based on a 10-20 MByte core system it's clear that NI CANNOT change it, even if they wanted...
The situation is similiar to the Scope SDK - noone has copied it (or ever will), because it just takes too much time

I also appreciate the different sound flavor of native processing (having a Granular and DevineMachine), but the question was if an increased CPU performance would lift typical native processing into the regions that DSPs are known (and appreciated) for.

In theory that's possible with even a mid sized current CPU, but reality of implementations is lightyears behind what a 10 years old SFP got included -imho

cheers, Tom

darkrezin · Post by **darkrezin** » Mon Jun 12, 2006 5:33 am

The problem is that current algorithms simply need to be similified in order to run efficiently on native CPUs. This is because the consumer hordes value multiple instances and lots of voices over a few good-sounding voices.

As I said, native processing will not equal DSP responsiveness, because of the buffer processing issue.

However, IMHO sound quality of VST will improve and equal or better other solutions.

Just because NI stuff sounds like shit doesn't mean it's not possible

[ This Message was edited by: darkrezin on 2006-06-12 06:34 ]

Shroomz~> · Post by **Shroomz~>** » Mon Jun 12, 2006 6:19 am

Looking at recording audio from another point of view, 24 bit ADCs have a lot of life left in them, since analogue waveforms don't contain enough information to warrant anything of higher resolution.

I think video & games will benefit the most from 64bit computing & for the foreseable future, I doubt very much that anyone in their right mind will buy into 48 or 64bit ADCs if they ever exist.

astroman · Post by **astroman** » Mon Jun 12, 2006 6:23 am

On 2006-06-12 06:33, darkrezin wrote:
...This is because the consumer hordes value multiple instances and lots of voices over a few good-sounding voices.
..., native processing will not equal DSP responsiveness, because of the buffer processing issue.
However, IMHO sound quality of VST will improve and equal or better other solutions.
...

yes, I agree on that - and I'd never devaluate native CPU processing by default.
The spectrum based restoration routines in the latest version of Wavelab look anything, but humble... for example.

I picked the NI example in the first place because it representats the M$ way of 'overbloating' things and selling old stuff as new by just re-labeling

It's about establishing defacto-standards that are easily extendible without any real innovation and preferably pay back by sub-licensing - a not so unusual strategy in IT business

you don't mention it explicetely but we probably agree that the main source for VST improvements will be experience and ideas, not just CPU power

cheers, Tom

[ This Message was edited by: astroman on 2006-06-12 07:26 ]

darkrezin · Post by **darkrezin** » Mon Jun 12, 2006 6:28 am

Of course... power is worth nothing without good algorithms to run on them. Algorithms require skilled and knowledgable coders. For example, Eventide stuff runs on standard Motorola DSPs as far as I know, but it sounds killer. That's because they have written some amazing algo's.

astroman · Post by **astroman** » Mon Jun 12, 2006 6:35 am

oops, another reason just entered my mind as you mention the other DSP platform...
DSPs are a better antiwarez strategy

not bulletproof (what is anyway ?), but keeps it out of bounds for at least 99%

cheers, Tom

Counterparts · Post by **Counterparts** » Mon Jun 12, 2006 7:44 am

For pure real-time number crunching DSPs have CPUs licked 'cos that's what they're designed to do. They are not general purpose processors.

Our company has recently done some mobile development work using a new dual-style processor; one half is a DSP chip and handles all the comms encoding and decoding whilst the CPU side handles all the UI and application level stuff.

Best of both worlds!

spoimala · Post by **spoimala** » Mon Jun 12, 2006 8:27 am

On 2006-06-12 05:04, darkrezin wrote:
(maybe this will change when true real-time operating systems exist for mass markets?).

There are numerous already, like LynxOS and QNX. Well, maybe not for mass markets... RTLinux may have most potential.

Btw, the term "realtime" is a bit confusing here. It really doesn't mean everything would occur in realtime. Instead, it does mean that everything happens at PRECISE time. The OS promises one schedule for processes and will keep it until the end of the world. Or here, process's lifetime.

In traditional OSes, you never know which process happens the postpone your process. In XP, your system timer process may take the most critical nanosecond from your sfp.exe

That's why you can change the process priority setting. But there's no way to guarantee noninterrupted running to any user process. Even the "realtime" setting is not really realtime, not even in the sense explained above.

The voice of a nerd has spoken.

darkrezin · Post by **darkrezin** » Mon Jun 12, 2006 8:34 am

Yes, I don't know enough about realtime OS's, as I haven't used any. I was speculating that maybe it would be possible to avoid the buffer-based method of native audio processing. But yes, it was pure speculation, I admit.

dawman · Post by **dawman** » Mon Jun 12, 2006 8:51 am

Then I am correct in assuming that dual and quad core CPU's will keep the power of the old style of programmabilty, while adding room 4 smarter and more efficient use of multiple cores, and 64 bit apps.
I suspect that we shall see some great stuff at NAMM in Janurary '07. Especially since the release of Conroe/Intel based solutions.
Brotha'Man Darkrezin, I will adding VST to my DSP/hardware ( Lexicon,Line 6,Studio Electronics SE1-x's ). I also enjoy multiple platforms. When one might become stagnant in terms of advancement, one of the other platforms will come into play. The best of both worlds, plus a constantly orbiing moon.

Strenth Through Superior Algorythyms,

astroman · Post by **astroman** » Mon Jun 12, 2006 1:46 pm

On 2006-06-12 09:51, scope4live wrote:
Then I am correct in assuming that dual and quad core CPU's will keep the power of the old style of programmabilty, while adding room 4 smarter and more efficient use of multiple cores, ...

that would be very nice, but unless for specifically optimized applications the performance gain is marginal, due to difficult scheduling of CPU tasks.

As you've already experienced with your boards, DSPs like Sharcs scale really well - twice as much chips result in nearly twice the performance.
Similiar architectures like the altivec engine in PowerPCs are also very effective, as they operate on certain parts of the processing that 'match' by structure and parameters.

But the process is hardly generalizable and much depending on how smart the respective compiler is - and of course the developer.
At least it takes a lot more effort and from what could be experienced in the past I'd assume the 'possibilities' of such features will be reviewed and hyped up and down, but few real world implementations will follow.

It's not the CPU task schedule that rules, but the release date of the product

Nevertheless upcoming systems WILL be faster, just like recent AMD64 CPUs (for example), which benefit from an overall improved design, faster memory(bus), more cache etc

cheers, Tom

astroman · Post by **astroman** » Mon Jun 12, 2006 1:48 pm

On 2006-06-12 08:44, Counterparts wrote:
...Our company has recently done some mobile development work using a new dual-style processor; one half is a DSP chip and handles all the comms encoding and decoding whilst the CPU side handles all the UI and application level stuff...

ADSP-21535 Blackfin ?