Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 08-11-2015, 01:47 PM   #1
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default Using live multiprocessing and groups causes HUGE CPU overload (threading error?)

I've noticed something strange with CPU usage a long time ago, but never found out the culprit till now.
(Error consistent with latest 4.x, and a clean install of Reaper 5 beta.)

It only happens when you use multiple record enabled tracks AND
you use at least one folder track, or one track that you send the multiple tracks to.

I've made some screenshots to make it easier.
(I've used a demo of the latest plugin 'Kaya' for it is very heavy on cpu, so it's easy to overload, but you can repeat it with most hungry plugins, or with loads of them.)

---------------------------------------------------------------------------
Basic scenario:
I have 6 tracks with 3 cpu heavy plugins on them, grouped to a folder with no plugin.
All set to live record (thus eleminating anticipative mode)
Everything looks good, the cpu is evenly stressed. RT cpu is at ~62%


----------------------------------------------------------------------------------------------------------------------------------------------------



Scenario Two:
I have enabeled a not much CPU heavy plugin* on the group, and BOOM:

RT CPU is off the charts, at 277%!!
On the CPU meter, you can see, it appears as every instance is now moved to one single core, overdriving it, while all the others do nothing!!
It's as if all the plugins in the group now chained in series on a single core.


----------------------------------------------------------------------------------------------------------------------------------------------------



Just for comparison:
I could add 5 of the same plugin that caused the overload, on EACH and every channel individually, and it still runs happily.

http://prntscr.com/83i3cd

It doesn't happen with every plugin though, i could add shitloads of AirEQ with all channels on, and it still works perfectly:

http://prntscr.com/83i2ih


I could understand it's a technical thing, or whatever, but what's strange in this, is that you can still stress the MASTER channel like you want

http://prntscr.com/83i7u5

and it works great, until you add one single plugin of the same to the group, and BOOM:

http://prntscr.com/83i8nu


Why i think it's some kind of 'bug' :

1. The MASTER channel can be considered a live group over all channels, and it doesn't show this error. So i guess it CAN be solved technically.

2. Just downloaded a Bitwig demo to test this, and it doesn't have this issue at all. I can route freely, and cpu hit is consistent.



* it's the free TDR VOS SlickEQ
HighVoltage is offline   Reply With Quote
Old 08-11-2015, 03:31 PM   #2
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Can you provide a screenshot of prefs/buffering?

Oh also the .RPP would be nice.

Thanks!
Justin is offline   Reply With Quote
Old 08-11-2015, 03:38 PM   #3
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

I wasn't able to make it misbehave following your instructions, however *muting* the folder track did cause it to fail miserably, which I am going to fix in the near future -- but enabling FX on the folder hasn't been an issue here.

My question about the prefs/buffering screenshot was: how many "live fx multiprocessing" cores do you have enabled? If it is 8 (the default, likely), it might be worth changing it to 4 (because of hyperthreading).
Justin is offline   Reply With Quote
Old 08-12-2015, 07:40 AM   #4
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by Justin View Post
My question about the prefs/buffering screenshot was: how many "live fx multiprocessing" cores do you have enabled? If it is 8 (the default, likely), it might be worth changing it to 4 (because of hyperthreading).
Thanks for the quick reply.

I indeed have 8 cores enabeled, i will do another testing, and will send the file and screenshot too.
Using the TDR VOS SlickEQ is ok?
I will try to find a cockos plugin if i can recreate it, so it's easier, but as i said, it doesn't happen with all the plugins, mostly the very cpu hungry ones.

So it's maybe partly caused by the plugins itself. (which is strange cause in Bitwig, it seemed, ok. I will do further testing there too)
HighVoltage is offline   Reply With Quote
Old 08-12-2015, 08:03 AM   #5
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Ok, i have tried with 4 cores, and it does the same.
Im using latest 5rc14, with a clean portable install, so everything should be on default, except the live multiprocessing.

Here are my settings:
http://prntscr.com/83sp3k
http://prntscr.com/83spgo

Attached a zip of the project. If you have a faster CPU, you might have to enable more FX on the sub channels. But even if i don't go over 100% CPU, the task manager still shows that its only running on one core as soon as i enable that single FX:
http://prntscr.com/83su0n
Attached Files
File Type: zip CPU TEST.zip (275.8 KB, 159 views)
HighVoltage is offline   Reply With Quote
Old 08-12-2015, 08:55 AM   #6
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Just a few other thoughts:

I found out that it's completetly irrelevant what kind of plugins are on the SUB channels, there are certain kind of plugins, that when enabled on a GROUP, they force all the sub channels to a single core.

Another thing, might be a clue:
I have inserted a plugin called MJUC on the GROUP, and i can put like more than 10 instances in a row, and CPU is evenly stressed. However this plugin has a HQ mode, and as soon as i switch it on, it instantly switches to the one core thing, overloading it to hell with only a single instance.
HighVoltage is offline   Reply With Quote
Old 08-12-2015, 12:44 PM   #7
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

I noticed this behavior with other plugins, too. Can't recall right now which. Probably also with oversampled EQ. Sometimes the CPU use is totally unpredictable, though I think in my case this is unrelated to having the tracks record-enabled.
I wonder whether this issue only occurs with oversampled plugins.
innuendo is offline   Reply With Quote
Old 08-12-2015, 01:14 PM   #8
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Hmm, I've just tested your project on Reaper 4.78 (haven't switched yet).
I can't reproduce what you see. But what's strange, I have exactly the opposite!
CPU use (both in Reaper's Performance Meter and in Windows Task Manager) is much *lower* when the effect on the group track is *enabled*. With it enabled, I see about 22% CPU use. With it disabled, I see between 29% and 37% CPU use. In both cases it's spread between 4 cores.
This anomaly only happens when tracks are record-armed...

Edit: if they are not record-armed, I see about 36%-37% CPU use with the effect on the group track disabled and yet slightly less when it's enabled...
P.s. tested with the "Dummy" audio driver, 512 samples...

Edit2: tested with Reaper 5, similar behavior: 22% with the effect enabled, 29% with the effect disabled. Master track effects state seems to not matter.

Edit3: tested on Reaper 5 with ASIO driver (RME UCX), similar results.

Last edited by innuendo; 08-12-2015 at 02:05 PM.
innuendo is offline   Reply With Quote
Old 08-12-2015, 02:16 PM   #9
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Thanks for testing. I'ts very strange indeed...

What CPU and MOBO are you using? (also at what buffer setting you get that 37%? I mean in ASIO mode)
HighVoltage is offline   Reply With Quote
Old 08-12-2015, 02:22 PM   #10
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Quote:
Originally Posted by HighVoltage View Post
Thanks for testing. I'ts very strange indeed...

What CPU and MOBO are you using?
It's a first-generation mobile i7 with hyperthreading. Specifically i7-720QM.
Toshiba laptop, mobo is based on the HM55 chipset.
innuendo is offline   Reply With Quote
Old 08-12-2015, 02:25 PM   #11
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Just tried this with the Dummy audio driver, and it downright crashed Reaper when i enabeled the GROUP plugin....
HighVoltage is offline   Reply With Quote
Old 08-12-2015, 02:27 PM   #12
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Quote:
Originally Posted by HighVoltage View Post
Just tried this with the Dummy audio driver, and it downright crashed Reaper when i enabeled the GROUP plugin....
I had a couple of crashes too, but only when closing the project. Seems to be referencing the plugin. Tried a couple more times, it doesn't crash every time.
innuendo is offline   Reply With Quote
Old 08-12-2015, 02:35 PM   #13
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by innuendo View Post
It's a first-generation mobile i7 with hyperthreading. Specifically i7-720QM.
Toshiba laptop, mobo is based on the HM55 chipset.
Well, that is very disturbing, My CPU (i7-4790k) supposed to be at least 4 times faster on paper than yours. With the same file, i get around 47% CPU hit with the group not enabeled!!

Btw.: Do you have anticipative fx enabled? Cause from your stats it seems like you have almost the same CPU hit with record enabled and not.

Last edited by HighVoltage; 08-12-2015 at 02:40 PM.
HighVoltage is offline   Reply With Quote
Old 08-12-2015, 02:42 PM   #14
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Quote:
Originally Posted by HighVoltage View Post
Well, that is very disturbing, My CPU (i7-4790k) supposed to be at least 4 times faster on paper than yours. With the same file, i get around 47% CPU hit with the group not enabeled!!
Hmm, a few questions:
- what buffer size are using for your audio interface? I'm currently on 256 samples.
- are you running a 32-bit version of Reaper?
- is CPU use on about 0% when Reaper is closed?
innuendo is offline   Reply With Quote
Old 08-12-2015, 02:49 PM   #15
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

BTW I tested this project with the 64-bit version of Reaper 5 (plugin is bridged). Here CPU use is as expected: 48% with the plugin disabled, 49% with the plugin enabled.
innuendo is offline   Reply With Quote
Old 08-12-2015, 02:54 PM   #16
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by innuendo View Post
Hmm, a few questions:
- what buffer size are using for your audio interface? I'm currently on 256 samples.
- are you running a 32-bit version of Reaper?
- is CPU use on about 0% when Reaper is closed?
Yeah it's 0% when Reaper not running. Plus i disabeled a lot of services, and almost all background applications, etc.. etc...
And it's the 32bit version at 256 samples.
HighVoltage is offline   Reply With Quote
Old 08-12-2015, 02:55 PM   #17
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by HighVoltage View Post
Well, that is very disturbing, My CPU (i7-4790k) supposed to be at least 4 times faster on paper than yours. With the same file, i get around 47% CPU hit with the group not enabeled!!

Btw.: Do you have anticipative fx enabled? Cause from your stats it seems like you have almost the same CPU hit with record enabled and not.
Are you sure this isn't a denormaling problem?
__________________
Music is what feelings sound like.
karbomusic is online now   Reply With Quote
Old 08-12-2015, 03:02 PM   #18
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Quote:
Originally Posted by HighVoltage View Post
Btw.: Do you have anticipative fx enabled? Cause from your stats it seems like you have almost the same CPU hit with record enabled and not.
With anticipative fx enabled, I see about 1.5x CPU use when tracks are not record-armed. With it disabled, there is no difference.
innuendo is offline   Reply With Quote
Old 08-12-2015, 03:04 PM   #19
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Are you on "high-performance" power plan?
innuendo is offline   Reply With Quote
Old 08-12-2015, 03:10 PM   #20
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by karbomusic View Post
Are you sure this isn't a denormaling problem?
I was sort of thinking that too...
Justin is offline   Reply With Quote
Old 08-12-2015, 03:48 PM   #21
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Please test with the attached project.
I don't see any anomalies here, CPU use is as expected.
Attached Files
File Type: zip CPU TEST-2.zip (265.4 KB, 131 views)
innuendo is offline   Reply With Quote
Old 08-12-2015, 04:13 PM   #22
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by innuendo View Post
Please test with the attached project.
I don't see any anomalies here, CPU use is as expected.
http://prntscr.com/83ytv8

Yes, this one is working as expected. All Cockos plugins work fine. But as i said, it only appears with certain plugins. I just randomply added different plugins on the GROUP channel, and i couldnt find ANY pattern. THere are developers, who's pugins are always causing trouble, like Variety of Sound (VOS).
But even Voxengo's latency delay, caused this, which introduces almost 0 CPU hit.
Klangheim's MJUC, doesn't do this, only in HQ mode. Note: I have reported a denormal issue to him in HQ mode, and he quickly released an update fixing it, so you guys might be on the right track with that.
Im on high performance power plan. And disabled all the CPU turbo things in BIOS. (core parking, C1E or whatever)

But then what can i do?

In Bitwig, i could add 23 channels each with 9 plugins, all record enabled, and i was playing live guitar on all the inputs at the same time without a crackle.

Too bad i love Reaper that much
HighVoltage is offline   Reply With Quote
Old 08-12-2015, 04:23 PM   #23
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

I'm seeing 210% RT CPU use with all the plugins enabled in this project. So probably your CPU is faster after all

BTW the figures I posted above referred to the total FX use indicator (the lowermost figure in the performance meter), not to RT CPU which is apparently disabled by default on a new installation of Reaper, which is why I didn't see it until looking closely at your screenshot.
innuendo is offline   Reply With Quote
Old 08-12-2015, 04:28 PM   #24
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Quote:
Originally Posted by HighVoltage View Post
http://prntscr.com/83ytv8

Yes, this one is working as expected. All Cockos plugins work fine. But as i said, it only appears with certain plugins. I just randomply added different plugins on the GROUP channel, and i couldnt find ANY pattern. THere are developers, who's pugins are always causing trouble, like Variety of Sound (VOS).
But even Voxengo's latency delay, caused this, which introduces almost 0 CPU hit.
About this, I also feel that some plugins misbehave in Reaper. If this doesn't happen in other DAWs, then perhaps we do have a bug here after all.
innuendo is offline   Reply With Quote
Old 08-13-2015, 07:17 AM   #25
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

I've just recreated the whole thing exactly at work.
It's just a dual core E8500, but still the problem persists.
But only when 'live multiprocessing' is on. When it was unchecked, i had the same results as Innuendo. When i enabled the plugin, cpu actually went down a notch...

before: http://prntscr.com/845qm1
after: http://prntscr.com/845r3p
HighVoltage is offline   Reply With Quote
Old 08-14-2015, 07:11 AM   #26
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

I've just replicated it on yet another computer. On Win7, Win8.0 and Win10.

But today i came home and it hit me!!!!
Any plugin that adds any PDC causes the error. Thats why MJUC worked great, cause it has 0 latency, but as soon as you set HQ, it adds 36 samples!!!
And thats why the problem was there with Voxengo Latency delay even thou it doesn't use any cpu. It just adds latency!

So i tested it and, every time it's the culprit. Even if i hit disable PDC on the plugin, CPU goes back to normal:

http://prntscr.com/84k7cz

http://prntscr.com/84k6ok


So can someone confirm this? I just replicated this on 3 separate computers. I think im going crazy.

This is a huge problem, cause i use a lot of realtime drum channels, and i constantly have 50%-70% cpu hit, and i dont even use that many plugins.
HighVoltage is offline   Reply With Quote
Old 08-15-2015, 07:26 AM   #27
VinodXAgent
Human being with feelings
 
Join Date: Nov 2013
Location: Hamburg
Posts: 749
Default

What is the problem? You simply don't use latency inducing plugins in recording (live) mode.
Vinod
VinodXAgent is offline   Reply With Quote
Old 08-15-2015, 07:41 AM   #28
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by VinodXAgent View Post
What is the problem? You simply don't use latency inducing plugins in recording (live) mode.
Vinod
The problem is:
1.
Yes I do. All the time.
And lot of plugins just add 3, 8, or 32 samples. I can happily live with 256 samples.

2.
I have now tested 3 other DAWs and none of them does this, so this is clearly something that should be addressed.
Not to mention that this is a huge waste of resources, and Reaper was always the leader in CPU utilization. Anticipative mode is a godsend.

Real life example:

I use a multi-output drum sample library, i add a few cpu hungry plugins here and there, RT-CPU is at 12%, i have to add a plugin to the group that has a 3 sample latency, and suddenly CPU goes to 78%, cause all the children are now processed serially on one core. That waste for me is hard to accept.

Last edited by HighVoltage; 08-15-2015 at 07:56 AM.
HighVoltage is offline   Reply With Quote
Old 08-27-2015, 08:09 AM   #29
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by Justin View Post
I was sort of thinking that too...
So i guess this won't be addressed?
HighVoltage is offline   Reply With Quote
Old 08-27-2015, 08:32 AM   #30
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by HighVoltage View Post
Real life example:

I use a multi-output drum sample library, i add a few cpu hungry plugins here and there, RT-CPU is at 12%, i have to add a plugin to the group that has a 3 sample latency, and suddenly CPU goes to 78%, cause all the children are now processed serially on one core. That waste for me is hard to accept.

Ah, so it is the addition of PDC on the folder track that causes it to blow up?
Justin is offline   Reply With Quote
Old 08-27-2015, 09:01 AM   #31
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by Justin View Post
Ah, so it is the addition of PDC on the folder track that causes it to blow up?
Yep!

And it even goes back to normal if i click 'Disable PDC' on folder plugins that cause the problem.
HighVoltage is offline   Reply With Quote
Old 10-16-2015, 11:11 AM   #32
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by Justin View Post
Ah, so it is the addition of PDC on the folder track that causes it to blow up?
Hi, sorry i promise i won't bother you anymore, but i would like to know if this gonna be addressed at all? This is a major workflow killer for me.

Meanwhile i made one more test, and it turns out that the anticipative mode is the main culprit here.

I don't even have to enable record on anything.


This is 4 channels of the same plugin on them 3 times.
Each instance takes around 8% CPU alone. RT cpu at 27%.
http://prnt.sc/8s0whb

As soon as i cascade the channels into each other, the whole system breaks up,
audio stops, and stutters, CPU is overloaded:
http://prnt.sc/8s0w3u

My cpu can handle LOADS more plugins even with anticipative OFF:
http://prnt.sc/8s0x05

So this means if you use group channels with PDC delayed plugins (even 3 samples)
And you WILL, cause 60-70% of plugins have some sort of delay.
Your CPU power DRASTICALLY drops. For no reason at all.
HighVoltage is offline   Reply With Quote
Old 10-16-2015, 11:38 AM   #33
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by HighVoltage View Post
As soon as i cascade the channels into each other, the whole system breaks up,
audio stops, and stutters, CPU is overloaded:
http://prnt.sc/8s0w3u
This is because there is a dependency chain here, each plug-in is dependent on the previous plug-in, so you essentially have 12 instances in a row, which is causing the overload.

Quote:
My cpu can handle LOADS more plugins even with anticipative OFF:
http://prnt.sc/8s0x05
And that has 9 instances of the plug-in per track, but each track can be processed in parallel to the other track (on different CPUs). What does it look like if you put 12 instances on a single track? I'm guessing it will come close to overloading.
Justin is offline   Reply With Quote
Old 10-16-2015, 11:53 AM   #34
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by Justin View Post
This is because there is a dependency chain here, each plug-in is dependent on the previous plug-in, so you essentially have 12 instances in a row, which is causing the overload.



And that has 9 instances of the plug-in per track, but each track can be processed in parallel to the other track (on different CPUs). What does it look like if you put 12 instances on a single track? I'm guessing it will come close to overloading.
Yes i know, BUT

If there is no PDC on the plugin, i can stack just as many, and reaper will process them all in a separate thread. This ONLY occours if there is any PDC on the channel that is being routed to.

And as i tested 3 other DAW's they all do this, i can use just as many plugins stacked, as in paralell.
And so can reaper, cause it definitely processes the Master channel on it's own thread. (not to mention without PDC too)
HighVoltage is offline   Reply With Quote
Old 10-16-2015, 11:57 AM   #35
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,562
Default

Quote:
Originally Posted by HighVoltage View Post
I've noticed something strange with CPU usage a long time ago, but never found out the culprit till now.
(Error consistent with latest 4.x, and a clean install of Reaper 5 beta.)

It only happens when you use multiple record enabled tracks AND
you use at least one folder track, or one track that you send the multiple tracks to.
Is this only when you use a folder track for a bus or does it still do it if you use universal tracks and normal sends to route to them?

I got introduced to Reaper after universal tracks were a thing, so coming from using analog mixing boards in the past, I only ever use standard sends/returns with universal tracks.

I experience issues due to buggy plugins too here and there and I also notice that Reaper has to be working on a larger project (lots of tracks, plugins, automation, etc) before the buggy plugins misbehave.

The best workaround I have for that scenario is to disable AfxP per track when using a suspect plugin. (Putting the track in rec mode also disables AfxP for that track as you noted.) Actually I disable AfxP for all 3rd party plugin inserts. Makes for happiness and light 99.99% of the time.


It seems like the root cause is something to do with PDC crashing. The suspect plugins I have that misbehave all either have a high latency for PDC to deal with (like the Waves linear phase multiband comp) or they report their latency incorrectly to PDC (like the Soundtoys Decapitator).
serr is online now   Reply With Quote
Old 10-16-2015, 12:48 PM   #36
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by Justin View Post
And that has 9 instances of the plug-in per track, but each track can be processed in parallel to the other track (on different CPUs).
Quote:
Originally Posted by Me
And as i tested 3 other DAW's they all do this, i can use just as many plugins stacked, as in paralell.

Ok i stand corrected, i just made an other round of testing, and the other 2 DAWS had the same cpu usage with stacked folders.
So i guess this is the only way it can be engineered.

But this still doesn't explain this at all:

On the group folder i put a lot of cpu heavy plugins, and everything works fine
http://prnt.sc/8s2esn

As soon i only put a single instance of a plugin that uses NO CPU at all (but has pdc)
http://prnt.sc/8s2g6r

All hell breaks lose.

---------------------------

Anyway realized, that the CPU meter of reaper in AfxP mode, is waaaaay off.
It just shows a totally incorrect number in AfxP. Is that normal?
I found that if i put 18 instances of a plugin

AfxP ON: Realtime CPU 86% Cpu 11%
AfxP OFF: Realtime CPU 0.3% Cpu 12%

12% and 86% ? That can't be true.

And in AfxP ON, cpu meter shows 12%, if i put another instance, i get breakups, and stuttering. So there is no way to really measure CPU in AfxP mode?
HighVoltage is offline   Reply With Quote
Old 10-16-2015, 01:12 PM   #37
ramses
Human being with feelings
 
Join Date: Jul 2009
Posts: 1,231
Default

I just want to report that I've been experiencing problems using the MJUC comp as well, lots of stuttering happening and sort of randomly as well. I've been using it on hq mode quite a bit, but I have not ran any tests yet. Nice if this issue could be sorted.
ramses is offline   Reply With Quote
Old 10-16-2015, 01:15 PM   #38
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by ramses View Post
I just want to report that I've been experiencing problems using the MJUC comp as well, lots of stuttering happening and sort of randomly as well. I've been using it on hq mode quite a bit, but I have not ran any tests yet. Nice if this issue could be sorted.
Did you update it to the latest version 1.0.2? That fixes a denormal issue in HQ mode, which caused ultra high CPU usage in MK3 mode (as far as i recall).
It's very stabile for me ever since.
HighVoltage is offline   Reply With Quote
Old 10-16-2015, 01:22 PM   #39
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,562
Default

Quote:
Originally Posted by HighVoltage View Post
And in AfxP ON, cpu meter shows 12%, if i put another instance, i get breakups, and stuttering. So there is no way to really measure CPU in AfxP mode?
Question:
Are you disabling AfxP globally in preferences/buffering?

Try this:
1. Enable AfxP globally in preferences/buffering.

2. After hitting apply, close and relaunch Reaper.

3. Go to preferences/buffering page again and set the number of audio threads to how many cpu cores you have (or select auto).

4. Now for every track with this suspect plugin inserted, disable AfxP just for that track. Right-click or ctrl-click the track, select Track Performance Options > Prevent Anticipative FX.


That make a difference?
serr is online now   Reply With Quote
Old 10-16-2015, 02:52 PM   #40
HighVoltage
Human being with feelings
 
HighVoltage's Avatar
 
Join Date: Jan 2007
Posts: 496
Default

Quote:
Originally Posted by serr View Post
Question:
Are you disabling AfxP globally in preferences/buffering?

Try this:
1. Enable AfxP globally in preferences/buffering.

2. After hitting apply, close and relaunch Reaper.

3. Go to preferences/buffering page again and set the number of audio threads to how many cpu cores you have (or select auto).

4. Now for every track with this suspect plugin inserted, disable AfxP just for that track. Right-click or ctrl-click the track, select Track Performance Options > Prevent Anticipative FX.


That make a difference?

No, that basically does the same as if i enable record on a track.

I think reaper calculates the cpu usage for a plugin divided by the number of cores you have.
If a plugin reports 2.5%, it really means 10% for one instance on 4 cores.
HighVoltage is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 07:26 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.