Topic: CPU & CPU usage meter: Pretty weird. (Solved)

@DFusion wrote:

Let me explain 🙂
If you have a single core it counts from 0 to 100%

Dual cores have a max of 50% on each core and Quad has 25% on Each core.

So if you use a program on a dual core setup and you disable Multithreading it only uses one core which maxes out at 50% and the other core works for background tasks outside of the program that is used.

So to sum it up:

Single core = 100%
Dual Core = 50+50 = 100%
Quad Core = 25+25+25+25 = 100%

So on a Dual core 50% is 100% on one core.

😀

Interesting. Thanks. How do you know this if I may ask? Any Microsoft links to read? 🙂

@bfloyd6969 wrote:

Ok, all this cpu talk has got me more curious and please try to answer me this – First let me state that I’m using an AMD Athlon 64 3500 2.20 GHz with Vista. I started a recent project I’m working on with a few midi tracks for now and the cpu meter in Podium is reading between 17 ~ 20%. I open my Task Manager cpu meter and it is reading 45 ~ 50%. This is with the Big Transport screen selected. Now, I switch to the standard Arrangement screen and the cpu in my Task Manager drops to 40% while the Podium cpu is still reading the same as it has been (17 ~ 20%). Now, I switch to the Split Mixer screen and my Task Manager cpu load drops to the same as what Podium shows, 17 ~ 20%. Any ideas about this???? I can’t have 50% cpu load with only a few tracks, and I can’t create arrangments while in the Split Mixer screen… I’m screwed. 😕

The CPU percentage that Podium shows is only for the audio engine. What you see in task manager includes UI processing. Updating the “big transport” display requires extra CPU by the UI thread, so it makes sense that you see an increase in task manager. If there is plenty of free CPU, the UI will use this to update the display smoothly. However the audio engine runs at a higher priority than the UI thread, so if the audio engine uses up more CPU, it will take away time from the UI thread. If the audio engine runs at 80-100% you may notice that the UI update of e.g. the play cursor can become more sluggish.

@LiquidProj3ct wrote:

@Zynewave wrote:

Popular topic 😉 . Let’s get to the bottom of this.

@LiquidProj3ct: Can you please email me your Podium and Reaper project files, so I can test it on my system.

My guess is that the improved performance you see on Reaper, is related to the “anticipative FX processing” option in Preferences/Buffering. You get better CPU utilization at the expense of larger latency response to realtime changes in plugin editors etc.

Sent!

However I don’t think that anticipative fx processing be so powerful. Orion can load 6 instances of Gladiator2 and its CPU usage in both cores are about 87% here. Reaper can load 7, due to anticipative.

Best regards

Thanks for the files. I’ve done some experimenting. I’m using the latest Reaper 2.55 instead of the 3.0 beta.

Is there any way you can make Reaper display if a buffer underrun has occurred? I can hear it happening increasingly when reaching 90% and beyond. That is using the “anticipative” option. When using the “synchronous” multiprocessing option I can hear spikes when as low as 55% on the Reaper CPU indicator, and that is with an ASIO buffer size of 1024 (23 ms). Depending on the ASIO buffer size, it sounds mostly like distortion. It can be difficult to hear if a single spike/buffer underrun occurs. A single buffer underrun will make the Podium cpu indicator spike into the red.

My initial tests confirm that the Reaper “anticipative fx processing” plays a major factor in the perceived CPU performance. Basically what it does is render all plugins offline ahead of time by default 200 ms, in a background thread. This evens out any CPU spikes that normally would occur with very short buffers. The downside to this is that any changes you make in the plugin editor will be delayed by 200 ms. If it’s an instrument, then notes you play via the editor keyboard will be delayed by 200 ms. If you “record arm” a track, then the multiprocessing of that track will be disabled. If you record arm all tracks, then all plugin processing will be performed on one CPU core only.

Podiums implementation of multiprocessing corresponds more to the other “synchronous fx multiprocessing” option in Reaper preferences/buffering dialog. This option will always process all plugins in realtime without prerendering. The benefit is that all plugins responds with low latency, no matter if the track is record armed or not. The downside is that there is a slight CPU overhead in the management of the synchronous processing. This overhead will be more noticeable with very short ASIO buffer sizes.

So if you have problems with CPU spikes in Podium, my usual recommendation still applies: Increase the ASIO buffer size.

If I set Reaper to use “synchronous fx multiprocessing” and disable “anticipative”, then I get the same task manager CPU usage using both Reaper and Podium. I also get more or less the same CPU spikes/buffer underruns, with the difference that Podium notifies the user of the spikes in the CPU indicator. That is running 6 instances of Gladiator in both Podium and Reaper, using your test projects.

Have you tried the DPC Latency Checker?
http://www.thesycon.de/deu/latency_check.shtml