Jump to content

How Much Cpu Does Samp.9 Use Per Vsti?


Recommended Posts

How much cpu does samp.9 use per VSTi? I'm talking about a VSTi like kontakt 2 loaded with no sample loaded, just the VSTi... Is it 2%?.., 5%?

Can anyone do this for me: load 3 to 4 instance of ''empty'' K2 VSTi and try to see how much cpu it takes?

If you don't have Kontakt 2, just use an other VSTi and it should be fine.

That would be really helpfull guys?


Link to comment
Share on other sites

The problem is CPU load on a relaxed system doesn't scale up for a system under stress.

So the maximum number of patches/voices you can run simultaniously would serve better as cpu load comparison.

Of course you can feel free to collect statistical data about CPU load, but it would be hard to draw any holding conclusions from the measurement you suggested.

Another basic principle in most DAWs is that GUI (graphic user interface) drawing will be suppressed if the system is under heavy load - so audio is still processed, but the GUI becomes sluggish. GUI perfomance shouldn't appear in the CPU load measure display, but it would appear in the windows task manager cpu load display, for example.

It also makes a difference if the VSTi is in monitoring mode (and then the ASIO buffer size) or not and if there are MIDI objects send to the VSTi or not.



Link to comment
Share on other sites

[While I was typing my blabla below, Frank already answered. But I add my words anyways.]

The CPU load mainly doesn't come from the host. Actually the plugin plays the larger role here.

Let's look behind the curtain:

The host (Sam, Cubase, Sonar, whatever) processes every bit of audio in small buffers (usually 64..2048 samples, depending on the ASIO/driver settings). Buffers are needed for the application to be realtime-capable. Consider buffer handling just like a manufacturing belt: You put something on the start of it, other workers process it along the way, hand it over to the next guy and someone receives it at the end and puts it into a box.

In technical terms, such a thing is a 'ring buffer', just like the belt it has a defined length. As long as it is long enough (or running slow enough), you can safe time through it and work quite effectively. Run it too fast / have too many workers handle things / have too time-consuming operations and your goods will tumble off the belt.

With VST, there are input & output buffers.

If you insert an effect plugin, it gets its input via such an input buffer, processes each containing sample one by one and writes the result to the output buffer, which is given back to the host program. In & out buffers have to be of the same size, for sure.

[Now, if you have a VSTi, the input buffer is usually non-existent or discarded, most hosts don't hand them to a VSTi. So, you only point the plugin to the output buffer and say how big that is. The rest is up for the instrument.]

Such buffer handling is happening in time slices; a buffer is given, processed, handed back, along comes the next etc.

Question is: how much time has a plugin got in order to fill a buffer? As said, it depends partly on the buffer size; small ones are fed up very quickly, while larger ones stay more relaxed. But one has to keep in mind that the host is still running at the fixed sample rate (e.g. 44k1), because we're doing realtime, it has to fetch the next buffer in order to keep up with the current speed.

So, at the end of a buffer size, the host says 'Plugin, gimme that damn buffer!'.

Plugin says: 'Are you joking? I've got 10 voices to process, each one with 6 oscs, 2 hi-end-analog-jummyjummy filters, high-class effects invented by outer-space intelligence... and you want me to hurry up??? No way!'

Then comes the crackling... we are literally stuck in time. If we were 'offline' (the opposite of realtime, such as wav rendering), we could easily wait for the buffer to get filled.

If the plugin were a cheap & tiny monophonic, 2 oscillator thingy with not much else going on, that would be smarter. It would probably bore itself to death before the end of a buffer run.

You see, it's very rarely a host thing (most of them are interchangeable in terms of bringing in their own CPU load). You can observe slight CPU load fluctuations with different driver models (ASIO, WDM) and by either using Sam's high- or low-latency engine.

But the more complex a plugin is, the more the constant load depends on its complexity, the algorithmical structure, the underlying processor (some CPUs/FPUs are quite fast but have bad caching schemes, some are slower but cache quite good and can predict things pretty clever etc.), the overall system throughput, amount of memory/cache and last not least, the audio hardware (buffer size, efficiency, CPU load).

So it's also a vague thing to compare CPU consumptions on different machines. There are benchmark tests for CPUs and graphic cards, but there's no 'standard' thing for audio yet.

You can freely test your VSTi's with the v8 demo and compare it to any other host you are used to. I guess the basic load doesn't differ that much. But when it comes to quite small buffers (I'd say < 512 samples), the internal regime plays a matter; this is where we've put much effort into with V9 and the hybrid engine: tracks without realtime input can stay 'relaxed' by handling large buffers, realtime tracks with VSTi input can get small ones to be as responsive as possible.



Link to comment
Share on other sites

Thanks guys, it's really great to get a reply by 2 devellopers, and that quick. :)

Sacha, thanks for explaining all this, it's gonna be really helpfull...And about Samp V9 hybrid engin etc.. I think it's a very good idea...

But the reason i was asking this question is, that i want to know if i should build my templates in VSTi mode(using FX-Teleport) or standalone mode(using midioverland). Now i tried using VSTi with FX-T in cubase SE and it works really well with 4 Pc. But the problem is that is takes around 5% for each instance of K2(empty that is), and since cubase SE start's acting weird at 50% cpu load and i'm building a big templates that will contain at least 400+ instruments, there's no way i can do that with Cubase cause i will run out of power before i can even play a sound...cubase is really bad when it come to cpu efficiency,..and i had the same problem with V-Stack BTW...So i think you see where I'm going with this. Will i be able to build my templates with VSTi instead of standalone with Samp?...Now If Samp V9 is as efficient(cpu) as Samp V7 using VSTi, then i think I'll be O.K. cause Samp V7 was really good in that regard and was way more efficient than Cubase too(and souded better too!). So i guess my question should be: is V9 as efficient as V7?

Anyway, i gues I'll found out soon cause the synthax guy say I'll get my copy this week...oh wait! he said that last week...and the week before. ;)...I'm sure it's worth the wait...but it would be really important for me to know this now becuase i could cancel a soundcard i ordered for my K2 standalone wich i wont need if i sue VSti with FX-T...

So if anyone can load a few empty K2 VSTi and let me, i would be most greatfull.

I hope i made sence cause it's 6:45 AM here in Canada and i really need to get some sleep. <_< He! A smilie just for me! :lol:;)

Thanks for the help guys.


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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.


  • Create New...