Why 'hardware' synths sound better ?

[JoPo]

Just wondering...

I don't have a huge synth knowledge : I make music with computer since only 15 years and before I played real 'hardware' instruments : drums, percs, saxo ; so I didn't spends hours, days, years on synths before. Maybe my ears are not enough trained.

Allmost all hardware synths are programed DSP (not sure for the spelling). They are DS ... P for processor and a code, so a software, to make the dsp works as the guy who made the code wants.
A soft synth is just the code and it is the computer processor which will understand that code and make souding the computer. I understand that the only difference is harware -> dsp, software -> computer processor.

Is a Digital Signal Processor so much different from a Central Processing Unit ?

Of course, there is also the analog sound output which means digital to analogue converter. Better are those converters, better will be the sound.

So if you have a very good sound card (as we all have here !!), why a sofware synth would sound less good than a hardware one connected to Scope via its digital output ??


I know that kind of question has been discussed a lot here.. But I'm asking especially to the synth creator expert guys who comes around here, just for my personnal knowledge. (and for anyone interested by this question...)

Merci !


ps : I use a lot of soft synths but I also have 3 hardware synths ..! And ... Scope !

[garyb]

gross oversimplification:
the difference between cpu and dsp is that dsp is dedicated calculations. the cpu has to do multiple tasks. a cpu can do the same work, but the type of systems that a cpu is used in require the processor to do lots of jobs. that allows a dsp chip to run more detailed processes because it won't need to be interrupted to do other jobs.

[JoPo]

I believe I understand...

But for me, the level of detail is made by the code, isn't it ? So if you ask to a CPU to work in deep detail, it will do it, as a DSP. With a dsp, as it is occupied only to one task, the latency must be much shorter.

I think the answer to my question is in the difference between DSP & CPU.
I found this (not searching very deep) :
http://www.edaboard.com/thread14160.html

Your oversimplification was a good resume... Are you in computer business, Garyb ? You look to know much on those amazing and mysterious things...


.................... But I'm still convinced that a cpu with the good code will generate an as good sound as a dsp .......................

[dawman]

That doesn't include the Analog Hardware that uses discreet circuits.
The day Native can emulate real hardware, I'll gladly switch, until then I eagerly await.
I'd love to walk around woith a laptop and a single 88 note controller, but alas, I am an aging Dinosaur who prefers breaking his nuts to carry better sounding gear.
They better fuckin' hurry up.....

[JoPo]

Sure ! That doesn't include the Analog Hardware that uses discreet circuits ! I should have specified it..
For them, I don't need explaination to understand that there is a sound difference... My ears are not that bad !


.... I don't have any .... Just some without any discreet circuits : congas, drums, bongo ... Just love percs ... No power supply needed ...

[garyb]

well, i'm in the computer business because of music and Scope....


yes, a cpu can do the same job, the imprtant thing is code. the advantage to using dsps of a host cpu, is that the dsp is capable of realtime operation and that really good code will quickly kill a cpu that has to manage the rest of your system as well as that one really good bit of code.

[dawman]

Which is why my buddy who was using Sonalksiss and the SplitComp by Algorithix swore by their quality. But they brought his E8400 to it's Knees.

[dante]

Its not just that the DSP is dedicated to its task unlike a normal CPU, its also the instruction set and internal architecture - as S|C say on thier website :

"The Sonic Core Hardware utilizes SHARC-DSPs from Analog Devices which are specially engineered for audio applications and are exclusively used for the 32-bit audio calculations. Due to their enormous power, the processed sound reaches you in realtime, warm and transparent like from analog hardware. "

For playback purposes, I dont think 'realtime' is neccessarily that good a qualification anymore. I can play LASS Session Strings (native Kontakt VST) in more-or-less realtime as well. But the native stuff just hasnt been built up around a dedicated audio architecture over the last 15 years like the S|C stuff. Mr Steinberg has focused on the tape recorder whereas Creamware S|C have developed the mixing desk & rest of the outboard outboard gear.

[Sounddesigner]

yes, a cpu can do the same job, the imprtant thing is code. the advantage to using dsps of a host cpu, is that the dsp is capable of realtime operation and that really good code will quickly kill a cpu that has to manage the rest of your system as well as that one really good bit of code.

Wich is why Native synths that even approach the sound quality of SCOPE eats up tons of cpu power and add lots more latency. The better the algorithms the more the latency (DIVA, Synthsquad, etc) and cpu use. And when multicore use is enabled on some plugins latency further increases .

[Sounddesigner]

Its not just that the DSP is dedicated to its task unlike a normal CPU, its also the instruction set and internal architecture - as S|C say on thier website :

"The Sonic Core Hardware utilizes SHARC-DSPs from Analog Devices which are specially engineered for audio applications and are exclusively used for the 32-bit audio calculations. Due to their enormous power, the processed sound reaches you in realtime, warm and transparent like from analog hardware. "

For playback purposes, I dont think 'realtime' is neccessarily that good a qualification anymore. I can play LASS Session Strings (native Kontakt VST) in more-or-less realtime as well. But the native stuff just hasnt been built up around a dedicated audio architecture over the last 15 years like the S|C stuff. Mr Steinberg has focused on the tape recorder whereas Creamware S|C have developed the mixing desk & rest of the outboard outboard gear.

Many Native developers can produce better algorithms then what they do but running them better in a 'timely manner' is problematic. The better the algorithm the more the latency usually. If i recall correctly this is why it took so long for Melodyne to be realized and released (more realtime operation was desired), also when running Ozone 5's reverb at 96khz there is extra latency intentionally added to prevent extreme cpu use (this is what some developers have to do). To run with lesser latency demands more cpu power and more complex algorithms often demmand more power. The Algorithmix LP Splitcomp is the best compressor but the latency it has is really long compared to others and it makes it unsuitable for certain sitiuations and naturally the more instances you have in your project the larger the buffer-size generally need to be wich affects 'Live' operation.

When you only have a couple plugins with large latency running in your DAW it may not be bad on your computer and workflow but when you have many high-quality plugins running that demmand large latencies the larger your buffer-size becomes, and if you run other stand-alone programs outside your DAW the more the dpc-latency increases wich forces your buffer-size up inside your host. The computer's Native enviroment is a cumulative-latency enviroment, once you take advantage of its general nature and run more programs latency increases, and once you upgrade to better algorithms latency increases. You in specific may not have a problem with latency ATM with Native but others who use different programs and plugins and who have different needs do, also some developers have problems with getting algorithms as good as they want because it's harder for them to operate in a 'timely manner'. The quickest way to see this is to take your most complex project with all your native plugins, audio, automation, etc and keep lowering the buffer-size you'll see more cpu use and may run into pops and clicks the more complex a project is/becomes; likewise with complex plugin algorithms. No matter how many cores it has truthfully a computer can only do one thing at a time. To run a complete project (effects, instruments, etc) with quality plugins on a computer at latencies as low as dsp's would be a mega strain and not even possible ATM.

I know Urs once stated "When it comes to sound quality computers become freakishly slow", he is the developer of some of the best Native synths. DSP's are focused strickly on the audio task so there's more cycles/speed for plugins. People try to use the computer with its general purpose O/S to do everything in the world simultaneousely i.e. synths, samplers, effects, automation, audio-streaming, Video, run the O/S, internet, DAW's, etc and the more powerful computers become the more multi-tasking is desired, thus more latency. It's great to have a second enviroment (dsp's) that you know stays fixed at ultra-low-latency and dedicated to the audio tasks, this is true for both users and developers; As stated in your S|C quote "the processed sound reaches you in realtime, warm and transparent like from analog hardware".


EDITED

[JoPo]

I'm glad to see that I was not so wrong ! Cpu could do the job but it must not forget he has the computer to run too !

[dawman]

Once you play a Solaris, you'll see the combination of design, with the proper amount of power, and great DSP Coder can take you a long way.

[Warp69]

You can get the same result from CPU's as you can from DSP's and vice versa.

You can't measure the quality of algorithms by looking at the latency. LP Splitcomp uses linear phase processing which is not possible in realtime (neither DSP, analogue or what ever) and will introduce latency. It's not the actual quality that introduce the latency but the process used for the algorithm.

[dawman]

So you going to make a 480LX for Scope...?

[djmicron]

You can get the same result from CPU's as you can from DSP's and vice versa.

This is true, but on dedicated dsp's some kind of calculation is faster, so the latest 3d render farms are gpu based and if we do a comparison between a good native synth such as uhe diva and the minimax, we can see the difference in therms of cpu load and the diva is hungry even on the latest cpu while the minimax runs flawlessly on the sharcs.

The difference between today and the past decade is that now quality is possible on native cpu, but quality and quantity together is still a limit.

You can't measure the quality of algorithms by looking at the latency. LP Splitcomp uses linear phase processing which is not possible in realtime (neither DSP, analogue or what ever) and will introduce latency. It's not the actual quality that introduce the latency but the process used for the algorithm.

i agree, latency is more about usability and not about quality, but not always the latency is related to the kind of process such as the one you have mentioned, because on native systems, the buffer increases with the required processing power.

Having all the recording studio based on native software, can be a problem when we need to playback and record at the same time, with dozens of plugins opened, some inserted plugin on the recording channel, with the singer asking for realtime signal in the headfone....this is why i use scope based hardware.

I think the next step for native software is strictly dependent on the power of the cpu.

[Sounddesigner]

You can get the same result from CPU's as you can from DSP's and vice versa.

It's not the actual quality that introduce the latency but the process used for the algorithm.

In order to get the high-quality the process used adds latency i.e. Oversampling, linear-phase, some complex modeling, Look-Ahead, and whatever else. Most high quality algorithms have more latency than lower-quality counter-parts due to these processes used as part of their algorithm and with Native enviroment it is cumulative into extremely large latency when these algorithms are put into a project in any big number thus your whole project pays a heavy price for those high quality algorithms. For Native to do the same as dsp and run realtime at same latency the power usage would increase dramatically with certain high quality plugins in the project (not even possible ATM for several reasons), people increase their buffer-sizes now with current available sizes to prevent extreme power-use (latency and high-quality are VERY much connected and correspond with each other just as more power-usage corresponds with higher-quality aswell, generally speaking). Even when the higher quality algorithm does'nt naturally have latency it may have to be added - like i stated Ozone 5's reverb had latency intentionally added to prevent extreme cpu use at 96khz when they improved its algorithm.



EDITED

[Warp69]

a comparison between a good native synth such as uhe diva and the minimax, we can see the difference in therms of cpu load and the diva is hungry even on the latest cpu while the minimax runs flawlessly on the sharcs..

You can't compare two different algorithms to measure performance. One with zero delay feedback filters with prediction (DIVA) and the other with normal delay feedback filters.

There's nothing special about DSP's, CPU's or GPU's - absolutely nothing.

If the algorithms are exactly the same, then the result will be identical. DSP's doesn't magically produce better result - nor CPU's or GPU's.

[petal]

There's a heathen among us.

[Sounddesigner]

'

a comparison between a good native synth such as uhe diva and the minimax, we can see the difference in therms of cpu load and the diva is hungry even on the latest cpu while the minimax runs flawlessly on the sharcs..

You can't compare two different algorithms to measure performance. One with zero delay feedback filters with prediction (DIVA) and the other with normal delay feedback filters.

There's nothing special about DSP's, CPU's or GPU's - absolutely nothing.

If the algorithms are exactly the same, then the result will be identical. DSP's doesn't magically produce better result - nor CPU's or GPU's.

But due to the O/S of the computer the performance differs with computers vs dsp for the SAME type algorithms latency wise; don't just look at DIVA look at any quality Native synth (Native starts out with higher latency due to buffer-size and it is Cumulative. And when a algorithm is too demmanding 'power-usage-wise included' some sort of Offline processing is often used wich is not a 'Timely manner').

And as far as power-consumption goes (The harnessing of the Processors power); the O/S plays a role in this as well wich is seen in benchmarks by ADK , DAWbench. When comparing Windows to Mac Windows was far more efficient core scaling with plugins and produced a greater result and when comparing older versions of Windows to newer versions the newer was more effiicient and yielded more instances, naturally the number of instances shrink as the buffer-size decreases (The compueter becomes less powerfull with less buffer latency). Also Native is limited by the Asio driver wich can be at full load while Task Manager is only reporting 10% use of computer. Every benchmark comparing uad to most powerfull computers by running the same plugin that's available for both platforms in a benchmark, the computer won but not to the extent it should have (i think one of the benchmarks showed the 6-core i7 computer at around 5x more powerfull then the UAD QUAD but its GFLOPS stated it should've been 10x more powerfull, obviously the O/S, Asio, DAW, etc (Native enviroment} are preventing the computer from being as powerfull as it should be as far as power/speed goes. Basically the benchmarks state that a plugin is more demmanding on a computer than it is on dsp's in many situations, and the results continue to worsen in some situations for computers (it becomes less then 5x the power). The computer's general purpose O/S and extreme multi-tasking while only truly being able to do one thing at a time all cuts into it's power/speed. When you're Natively simultaneously running DAW's, instruments, effects, automation, Audio tracks, sound-card drivers, Video-card drivers, internet, the O/S, Antivirus software, etc etc that speed of the computer is reduced. The reduction of the speed is often compensated for to a extent by raising the buffer-size of your DAW but none-the-less the speed is reduced.

Merging Technologies was GREATLY impressed with the performance they got out of a computer when they BYPASSED THE O/S for their Pyramix DAW.


EDITED

[dante]

There's nothing special about DSP's, CPU's or GPU's - absolutely nothing.

If the algorithms are exactly the same, then the result will be identical. DSP's doesn't magically produce better result - nor CPU's or GPU's.

Then what are the philosophical differences between DSP's, CPU's and GPU's that have positioned them as specialists for thier given application ? Thier reason for existing, if you like.

Or might manufacturers just as well be throwing intel CPU's onto 3D gaming cards and Avid HDX cards (if not now, then in future, when the software catches up ?)