Jump to content

CPU Use by different DAWs


irvin
 Share

Recommended Posts

Simple fact is: the way Samplitude reports CPU consumption (or whatever you want to call it, we all know what we are talking about) is cryptic at best.

Samplitude doesn't report CPU use, and it is also good that it doesn't because CPU use is not directly related to the performance of a DAW. I.e., running a single signal through a DAW running on a Computer with 8 threads will result in max. 12,5% CPU load. Any little bit higher will result in drop-outs. Samplitude reflects that circumstance by displaying app. 100% DSP load in that situation, because there is no way to use any other thread for the task (that is running the processing on track, Master, or Bus). Would you distribute the same processing load to two tracks, you would see half the DSP% figures. Therefore, the way Samplitude does measure load is very much appropriate, while a CPU% metric would understate the situation.[i tired the "mission impossible", hope you appreciate.]

Don't blame users for that

My complaint you are juggling with numbers you don't understand, and which you declare that you don't understand them. That attitude is not ok, and neither is the attempt to defend your attitude by the allegation that your were "prevented" to understand by "mysteries". That's your problem, not MAGIX', not mine, not anybody else's.

Samplitude shows a significantly lower capacity for running plugins when compared to other applications.

Fair enough. However, your contributions add very little insight to your respective observation. My observations don't concur to that directly. I have seen worse, same, and better performance in Samplitude and other DAWs.-S

Too convoluted. It would be best for Samplitude to show something users can understand without going through the acrobatics. In the end, all a user wants to know is how much of the processing power is left (or used) at any given time.

What's the point of Samplitude reporting a "67% DSP (200% MAX)" usage? What does that even mean to a *musician*? Remember that this thing is for people making music, not programmer wannabes...lol....

Link to comment
Share on other sites

Actually, you will see that the processor is overloaded. But you may see that the CPU load is less than 10% at the same time

Therein lies the problem...lol...get it?

Is the processor overloaded or is its load less than 10%? The lady or the tiger? Who is the tallest midget on earth? The shortest giant? Fantastic...

(and before you come up with the usual pseudo-technical bs, please, remember - once again - this is for musicians, not programmer wannabes)

Link to comment
Share on other sites

In the end, all a user wants to know is how much of the processing power is left (or used) at any given time.

The DSP% metric tells you exactly that. A CPU% metric will understate most of the time on any system with more than one thread. So, what is better?

What's the point of Samplitude reporting a "67% DSP (200% MAX)" usage?

It means that you had a drop-out for sure since last playback start. You may have missed to notice.

Link to comment
Share on other sites

Is the processor overloaded or is its load less than 10%?

That can happen on a multi-threaded system. However, DSP% takes into account which resources it will currently see, and give the specific numbers.

No - the processor CAN NOT be overloaded and working at a 10% load AT the same time. Stop the nonsense, please.

In any case, let's not get sidetracked by silly pseudo-technical arguments. Let's go back to the original topic: why does Samplitude seem to have a significantly lower capacity for running plugins versus other applications under similar circumstances?

Link to comment
Share on other sites

Sorry Sebastian, but the manual says two sentences that lead anyone reading it to think that DSP and CPU is the same, it does in no way try to explain differences, I have no idea where you get that from.

It is fact that it's not the same, this linked thread here and the screenshot show quite nicely that there is a huge difference. Problem in this case is simply the manual stating something wrong, as simple as that.

http://support2.magix.net/boards/samplitude//index.php?showtopic=30185

The problem is that obviously nobody can or wants to explain the difference. I appreciate that you try, but honestly, you're the worst teacher on this planet. If someone asks you where he can find the car keys, you're explaining the complete history of Mercedes and BMW, how the engine works on a scientific level and all sorts of NASA-stuff, but in the end still no one knows where the car keys are.

Why the hell is it so difficult to give a simple and straight answer to a simple question? See yourself as a teacher and the others as schoolkids if it makes you happy, I don't care. But don't forget: You can't teach a schoolkid how to add 2 and 2 by trying to explain relativity.

For heavens sake Sebastian, you keep doing that all the time. The real pity about it is: it makes your answers and explanations worthless for a lot of people.

R

Matt

Link to comment
Share on other sites

BTW, I'm not arguing that Samplitude is doing anything wrong. I'm saying the CPU consumption report is cryptic at best. If Samplitude does takes into consideration everything going on with the computer at any given time(which I think it does), it should provide users with a simple "Running at 45% System Capacity" message. To most people it would indicate you have enough room to add a lot more plugins, for example, or record many more tracks.

Keep it simple.

Link to comment
Share on other sites

If Samplitude does takes into consideration everything going on with the computer at any given time(which I think it does),

Samplitude takes into consideration what it sees. It actually leaves out of the equation what could be there, but is not usable, i.e. n cpu treads that cannot be spawned by Samplitue because there is only one signal to process.

What it does is a time measurement. For 48 smpl the maximum allowed processing time @ 48 kHz is 1 ms. Say, the buffer comes back in 0,5 ms, you have 50% DSP load. For CPU%, you ask the system how much stressed the CPU is, and it will tell you that the CPU has lots of resources free.

it should provide users with a simple "Running at 45% System Capacity" message.

"System capacity" is not very obvious, as I have tried to make clear. You can't use more than one CPU thread with a single audio track. The user could not change that.

To most people it would indicate you have enough room to add a lot more plugins, for example, or record many more tracks.

Just for the sake of completeness: Recording doesn't cost any CPU on modern platforms. It's a chain of buffer copies that end up on disk at some point.

-S

Keep it simple.

Stupid!

LOL:

Link to comment
Share on other sites

If Samplitude does takes into consideration everything going on with the computer at any given time(which I think it does),

Samplitude takes into consideration what it sees. It actually leaves out of the equation what could be there, but is not usable, i.e. n cpu treads that cannot be spawned by Samplitue because there is only one signal to process.What it does is a time measurement. For 48 smpl the maximum allowed processing time @ 48 kHz is 1 ms. Say, the buffer comes back in 0,5 ms, you have 50% DSP load. For CPU%, you ask the system how much stressed the CPU is, and it will tell you that the CPU has lots of resources free.

it should provide users with a simple "Running at 45% System Capacity" message.

"System capacity" is not very obvious, as I have tried to make clear. You can't use more than one CPU thread with a single audio track. The user could not change that.

To most people it would indicate you have enough room to add a lot more plugins, for example, or record many more tracks.

Just for the sake of completeness: Recording doesn't cost any CPU on modern platforms. It's a chain of buffer copies that end up on disk at some point.-S

Keep it simple.

Stupid!LOL:

Too convoluted. Keep it simple.

Link to comment
Share on other sites

Trying to explain Sebastians's info in one simple sentence: If one thread is chooked up to 100% by a nasty plugin, then you will read 100% DSP processing even if the other 7 threads of a 4-core CPU are unused (the CPU load may display 12.5%!!!).

The plugin processing of one track can't be splitted over other cores or threads. Therefore the DSP use can be 100% because of one heavy track, while the whole CPU use is much lower (because the CPU's other cores/threads are processing much lighter tracks or hardly doing other things than system handling).

Does that make it clear?

Best regards,
Bertil

Link to comment
Share on other sites

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...