|
|||
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 | ||
|
|||
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 | ||
|
|||
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 | ||
|
|||
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 |
|||
| ^ | Joined: 20 Dec 2005 Member: #91716 | ||
|
|||
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. |
|||
| ^ | Joined: 13 Mar 2004 Member: #16800 | ||
|
|||
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 | ||
|
|||
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 | ||
|
|||
munchkin,
Could you download this latency checker and report back what it finds? http://www.resplendence.com/latencymon ---- bluzkat |
|||
| ^ | Joined: 17 Apr 2008 Member: #178643 Location: Lansing, Michigan | ||
|
|||
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 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 | ||
|
|||
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 | ||
|
|||
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 | ||
|
|||
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 | ||
|
|||
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 | ||
|
|||
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 | ||
|
|||
bluzkat wrote: munchkin,
Could you download this latency checker and report back what it finds? http://www.resplendence.com/latencymon 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 |
| KVR Forum Index » Hosts (Sequencers, DAWs, Audio Editors, etc.) | All times are GMT - 8 Hours |
|
Printable version |
Disclaimer: All communications made available as part of this forum and any opinions, advice, statements, views or other information expressed in this forum are solely provided by, and the responsibility of, the person posting such communication and not of kvraudio.com (unless kvraudio.com is specifically identified as the author of the communication).
Powered by phpBB © phpBB Group















