Plug-ins, Hosts, Apps,
Hardware, Soundware
Developers
(Brands)
Videos Groups
Whats's in?
Banks & Patches
Download & Upload
Music Search
KVR
   
KVR Forum » Hosts (Sequencers, DAWs, Audio Editors, etc.)
Thread Read
Reaper and CPU Load
Goto page Previous  1, 2, 3  Next
EvilDragon
KVRAF
- profile
- pm
PostPosted: Fri May 11, 2012 8:15 am reply with quote
There are some plugins out there that are using the benefits of multicore processing. Let's name Kontakt and Pianoteq here, and yes, Diva as of recently.
^ Joined: 06 Jan 2009  Member: #197719  Location: Croatia
munchkin
KVRAF
- profile
- pm
PostPosted: Fri May 11, 2012 9:44 am reply with quote
EvilDragon wrote:
There are some plugins out there that are using the benefits of multicore processing. Let's name Kontakt and Pianoteq here, and yes, Diva as of recently.


I'll experiment with Reaper to see if the CPU load per track limitation disappears when using a multicore plugin. In theory it might work because the plugin is allocating CPU load rather than Reaper.
^ Joined: 12 Oct 2002  Member: #4071  Location: Terra Firma
ph0bic
KVRist
- profile
- pm
PostPosted: Thu Jun 28, 2012 5:51 am reply with quote
Looks like I'm a little late to the party on this thread, but apparently, according to the following thread from 2008 it's a well known bug/ behaviour, that doesn't look like it's been changed:

http://forum.cockos.com/showthread.php?t=22865

Not sure if this was the thread that hibidy was searching for or not. The op argues that he has one core maxing out while his other 3 cores are idle, due to the fact that he is only recording on one track. As you will read, it goes a little off topic, with the op getting a bit of a hard time from some of the posters, but there is a suggested change to preferences on the final page that may help, although it didn't make any difference to myself.
HTH
^ Joined: 28 Nov 2009  Member: #220541  
hibidy
KVRAF
- profile
- pm
PostPosted: Thu Jun 28, 2012 2:15 pm reply with quote
I can't remember anymore. The only thing I know is if I load up my template in reaper, it's not a problem. Sonar, something like that might work. FL, S1 would just be shit outta luck. Same computer, same specs. So, though I occasionally hear about people with issues in this area in reaper, it's pretty rare.

Computers, they suck........mostly HiHi
^ Joined: 20 Dec 2005  Member: #91716  
No_Use
KVRian
- profile
- pm
PostPosted: Thu Jun 28, 2012 2:26 pm reply with quote
ph0bic wrote:
Looks like I'm a little late to the party on this thread, but apparently, according to the following thread from 2008 it's a well known bug/ behaviour, that doesn't look like it's been changed:

http://forum.cockos.com/showthread.php?t=22865


(OT)

Thread starter:
General Contact Unit

Damn I remember this guy.
If someones's bored and needs some entertainment dig for some of his posts...
And he left the Reaper forum with exactly 666 posts. I think this alone tells something. Very Happy
^ Joined: 13 Mar 2004  Member: #16800  
hibidy
KVRAF
- profile
- pm
PostPosted: Thu Jun 28, 2012 2:32 pm reply with quote
I don't know of him, but let's not start bashing people on reaper forums.......KVR will explode.
^ Joined: 20 Dec 2005  Member: #91716  
No_Use
KVRian
- profile
- pm
PostPosted: Thu Jun 28, 2012 3:02 pm reply with quote
Uh oh you're right, sorry.

(bit more seriously, the above was more of a very intuitive post when I read and remembered that name, but telling bad is no good, true dat)
^ Joined: 13 Mar 2004  Member: #16800  
bluzkat
KVRist
- profile
- pm
PostPosted: Fri Jun 29, 2012 4:39 am reply with quote
munchkin,

Could you download this latency checker and report back what it finds?

http://www.resplendence.com/latencymon


Cool
----
bluzkat
^ Joined: 17 Apr 2008  Member: #178643  Location: Lansing, Michigan
ph0bic
KVRist
- profile
- pm
PostPosted: Fri Jun 29, 2012 6:11 am reply with quote
hibidy wrote:
I can't remember anymore. The only thing I know is if I load up my template in reaper, it's not a problem. Sonar, something like that might work. FL, S1 would just be shit outta luck. Same computer, same specs. So, though I occasionally hear about people with issues in this area in reaper, it's pretty rare.

Computers, they suck........mostly HiHi

This is really noticeable to me whenever I rewire Reason into Reaper onto one stereo track. Straight away you see the effect (ie one core working and 3 cores idle). The same track in Reason standalone will typically utilise 3 cores leaving one presumably for op system tasks etc. So it's seems that it's not a processor issue here it is a software one.
Not sure if you still own Reason, but if so it would be interesting to test this with and without your template to see if the template settings actually make a difference to this behavior in Reaper.
^ Joined: 28 Nov 2009  Member: #220541  
LawrenceF
KVRAF
- profile
- pm
PostPosted: Fri Jun 29, 2012 7:30 am reply with quote
My limited nderstanding is that it's not a plugin instance that can't be split up, but an entire daw channel, a thread. If you have 5 plugs inserted on one track they all (afaik) go to the same thread and same core. Is that right?

That's my understanding anyway. That it's the threads themselves that can't be split up. Multi-slotted instruments like Kontak obviousy use multipe threads for multiple slotted instruments, which can go to multple cores. Can one slotted insteument be split across two threads, two cores?

Maybe the dsp guys around can clarify and/or correct that if it's wrong... but cores process threads, not partial threads.
^ Joined: 04 Dec 2004  Member: #50422  
jupiter8
KVRAF
- profile
- pm
- e-mail
PostPosted: Fri Jun 29, 2012 7:49 am reply with quote
LawrenceF wrote:
My limited nderstanding is that it's not a plugin instance that can't be split up, but an entire daw channel, a thread. If you have 5 plugs inserted on one track they all (afaik) go to the same thread and same core. Is that right?

Well you can but it makes no sense.

Plugin A -> Plugin B -> Plugin C

Plugin A needs to process it's buffers first before Plugin B can start. You simply cannot do them at the same time. So there's no point in putting them in separate threads. That'll actually increase the CPU load.

A single plugin can run on multiple threads/cores but for the vast majority of them it makes no sense. Id it can run on one core it will be much more efficient than if it's split up on several. The case where it makes sense is obviously if one plugin alone overloads a single core but do note that the plugin actually takes more CPU by doing so.

EDIT: So it's not a bug,it's the laws of physics i'm afraid.
----
At school they taught me how to be.
So pure in thought and word and deed.
They didn't quite succeed.
^ Joined: 17 Sep 2002  Member: #3863  Location: Gothenburg Sweden
Kaboom75
KVRian
- profile
- pm
- e-mail
- www
PostPosted: Fri Jun 29, 2012 8:04 am reply with quote
DIVA has been multicore for over two months now it has the option for it this works really well if you only run one demanding instrument in your DAW. DIVA with the multicore enabled sucks away all the CPU from the other tracks. I find it better to run lots of demanding instruments with DIVAs mulicore turned off.

The most ideal way is to have each track run on its own core. Six core CPUs exist but they depend on how a DAW alocates a core or thread.
^ Joined: 04 Sep 2011  Member: #264056  Location: England
kbaccki
KVRian
- profile
- pm
PostPosted: Sat Jun 30, 2012 2:13 am reply with quote
jupiter8 wrote:
LawrenceF wrote:
My limited nderstanding is that it's not a plugin instance that can't be split up, but an entire daw channel, a thread. If you have 5 plugs inserted on one track they all (afaik) go to the same thread and same core. Is that right?

Well you can but it makes no sense.

Plugin A -> Plugin B -> Plugin C

Plugin A needs to process it's buffers first before Plugin B can start. You simply cannot do them at the same time. So there's no point in putting them in separate threads. That'll actually increase the CPU load.

A single plugin can run on multiple threads/cores but for the vast majority of them it makes no sense. Id it can run on one core it will be much more efficient than if it's split up on several. The case where it makes sense is obviously if one plugin alone overloads a single core but do note that the plugin actually takes more CPU by doing so.

EDIT: So it's not a bug,it's the laws of physics i'm afraid.


If Plugin A or B or C is itself multi-threaded (like Kontakt), then the fact that the data flow is required to be serialized from A => C has no overall bearing on wheher an "individual DAW channel" is represented by one thread-core binding, or multiple thread-core bindings. If the DAW allows it, a single multi-threaded plug sitting in a FX bin can be physically bound to multiple cores are the same time -- assuming the plugin knows best, and it makes sense to do so.

Thread binding to cores and individual "DAW channels" are independent unless the DAW is explictly coded to bind all threads from an FX chain to a single core -- as mentioned in the recent MIDI thread, Logic currently (AFAIK) binds all threads from indivdual FX chains (from racks, busses, etc.) to individual cores. The mechanism for breaking up the core binding is for the user to explcitly remap their FX chains using sends and groups. Other DAWs don't have such restrictions on core distribution for single FX chains.

Consider A, B, C as each being a multi-threaded plugin… given some block of audio data let's say each plug represents a processing algorithm that can be logically and practically parallelized (parallel DSP functions at the CPU level notwithstanding, which is another level of MIMD/SIMD parallelization provided by modern CPUs). Let's say A is some reverb that physically models a 3D space and uses ray tracing to bounce sound waves around -- the space can be subdivided into "processing zones". Let's say B is some crazy filter operation where the filter matrix itself can be broken into sub-matrices, etc. etc. From a threading perspective you might be looking at something like this:


                  Threads          Threads
 
                /--\               /--\
(input) => A in ---- A out => B in ---- B out => etc.
               \ -- /             \ -- /
                \--/               \--/



If the individual threads are freely bindable to cores, then that single FX chain is effectively distributed across cores. In the case of Logic (again, AFAIK) all 12 threads are stuck on the same core. Note that at each of the "output" points of each plug you need to synchronize the output of the respective 4 threads… that's where things get complicated, and where you need to weigh the cost of synchronization to the benefit of splitting the operation across multiple threads to begin with. It's like buffering and caching… sometimes too much buffering causes you to do more work than less buffering… always a sweet spot.
Last edited by kbaccki on Sat Jun 30, 2012 2:33 am; edited 1 time in total
^ Joined: 12 Sep 2004  Member: #40510  
jupiter8
KVRAF
- profile
- pm
- e-mail
PostPosted: Sat Jun 30, 2012 2:33 am reply with quote
Or in short, unless a single channel takes more CPU than a single core can muster, it makes no sense running them on several cores. That would actually end up taking more CPU overall.
----
At school they taught me how to be.
So pure in thought and word and deed.
They didn't quite succeed.
^ Joined: 17 Sep 2002  Member: #3863  Location: Gothenburg Sweden
munchkin
KVRAF
- profile
- pm
PostPosted: Sat Jun 30, 2012 10:13 am reply with quote
bluzkat wrote:
munchkin,

Could you download this latency checker and report back what it finds?

http://www.resplendence.com/latencymon


Cool


I've just checked this thread again and the debate continues. I'll try the latency monitor but what should I be checking? ATM I've resigned myself to limiting the plugin load on each Reaper track so I don't exceed the single core limitation. If there's a solution to this limitation then I'm still keen to find it.
^ Joined: 12 Oct 2002  Member: #4071  Location: Terra Firma
All times are GMT - 8 Hours

Printable version
Page 2 of 3
Goto page Previous  1, 2, 3  Next
Display posts from previous:   
ReplyNew TopicPrevious TopicNext Topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Username: Password:  
KVR Developer Challenge 2012