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

… disregard my performance discussion in my “Future” thread. What LiquidProj3ct is reporting is precisely my issue. I fired up Reaper, and sure enough I have “Synchronous FX multiprocessing” unticked and “Anticipative FX processing” ticked. As per Reaper’s help info: “synchronous FX multiprocessing … isn’t ideal for the lowest latencies”, and “Anticipative FX processing … good for pretty much all systems”.

Now, you note that,

@Zynewave wrote:

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.

This is certainly why my system isn’t performing as expected — Podium’s audio processing is configured to exactly the opposite of my Reaper config.

@Zynewave wrote:

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

Um, no, this isn’t good. That’s the whole point of allowing people to configure Reaper in such a way: I run at ~6ms latencies (256 samples @ 44.1KHz) with these settings. I do lose the ability to tweak plugin editor parameters at low latencies, but why would I need to? Live performance? I’d use a MIDI controller, not a mouse. And with the Reaper settings, my VSTs all respond to my MIDI keyboard with no discernible delay.

@Zynewave wrote:

If it’s an instrument, then notes you play via the editor keyboard will be delayed by 200 ms.

Again, I don’t get it. Can you click a melody in a VST editor keyboard quickly and accurately enough that this matters at all?? (Note: if yes, I am officially alarmed 😉 )

@LiquidProj3ct wrote:

Frits, is posible disable the auto-mute when CPU is overloaded? It would be pretty useful in systems as mine, as I’ve seen with DPC Latency Checker, thx DFusion.

Best regards

I’ve added a “bypass processing when detecting CPU overload” option to the preferences dialog. When you disable this option, it will not mute the plugins when CPU surges occur. The UI may become sluggish if the CPU overload is sustained over a long period. The CPU indicator will still flash red to indicate that you most likely had a glitch in the audio output.

@adlaius wrote:

I’d use a MIDI controller, not a mouse. And with the Reaper settings, my VSTs all respond to my MIDI keyboard with no discernible delay.

@Zynewave wrote:

If it’s an instrument, then notes you play via the editor keyboard will be delayed by 200 ms.

Again, I don’t get it. Can you click a melody in a VST editor keyboard quickly and accurately enough that this matters at all?? (Note: if yes, I am officially alarmed 😉 )

I’m not sure about all this, but I would think your MIDI keyboard should also have the same delay. If it is pre-rendering, for instance, 200ms then it should also take 200ms for your MIDI keyboard notes to come through. That is definitely NOT low latency. Unless, when you are controlling track/s with a MIDI keyboard, Reaper then sets the track/s to not pre-render. While I don’t really see a problem with this, it DOES mean that when you record a track, Reaper needs to move the recording back the amount of delay of pre-rendering.

So either you ARE getting latnecy with your MIDI keyboard, or Reaper has disabled pre-rendering wherever you play it, unless I’m missing something.

It isn’t that bad of an idea actually, but maybe there would be problems with the lack of synchronising between tracks. Perhaps some kind people (especially Frits) could provide a practical theoretical example of a situation and consequence of the “anticipative” method. Not just its effects but perhaps a real life nuisance that annoys some people.

I’d probably use such a method, based only on my current understanding, but I have to admit that tweaking knobs, via MIDI keyboard or the user interface, having a delay would bother me some, tweaking becomes more of a guess and trial rather than a smooth test (not exactly, but still somewhat). I know you said you don’t notice a difference, but then if you were to only use one track and Reaper disables anticipative because of MIDI control, and you’re using something so CPU intensive, you will just have the same problem that synchronous would. Not a real situation probably, but that means there are still circumstances where both sides are equal. If Reaper wanted to be thorough of that method, wouldn’t it pre-render EVERYTHING? Not practical of course, but I can’t help feel there would be problems pre-rendering some and not other.

As I said, perhaps someone can discuss real-world examples of where anticipative causes real troubles, and what those troubles are.

@bfloyd6969 wrote:

@Zynewave wrote:

Did you read my previous reply to your post about CPU usage?

Have you tried maxing out the Podium audio engine with only 4 tracks playing? If so, what are the symptoms. Is the sound glitching, or is it just the CPU indicator that flashes red?

I must have missed that one (been a busy thread). I’ll try to max the buffer settings on the ASIO control and see what happens. What effect will maxing the buffer have on playback and latency though?

Maybe we are refering to two different things here also – when I mentioned the cpu load being high, I am refering to the Task Manager cpu load. The Podium cpu load never changes regardless of what Arrangement Screen I use.

From my previous reply:

@Zynewave wrote:

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.

So don’t worry that the task manager shows a higher percentage than the Podium CPU indicator. The extra CPU is used by the UI, and this will automatically be reduced when the audio processing requires more CPU.

@druid wrote:

As I said, perhaps someone can discuss real-world examples of where anticipative causes real troubles, and what those troubles are.

This is very interesting and maybe warrants a thread on the Reaper forum too. I knew how Anticipative processing worked (I think Digital Performer on Mac does something similar only they call it “pre-rendering”) but I thought that was a good idea – now, for the sort of workflow I have, I’m not so sure, and it might even account for some things I’ve noticed with some plugins in Reaper.

So let me get this straight – if the anticipative buffer is set to say 200ms then anything I do to the gui while playing in realtime (say tweak the filter cutoff) will be subject to 200ms latency? I just about do everything in realtime – i.e. I play instruments, often softsynths, and record as I go along using automation to capture expression (such as changes to knob positions using my mouse or NI Kore). I never compose using the mouse (though I might use the mouse to edit or tidy up afterwards). Would that scenario be affected badly by having anticipative on or would it still be be better than synchronous? As a player I want the lowest latency possible without compromising sound quality.

Also I’m wondering how this would affect things if I was using a DSP based instrument – I have a Virus Ti for example and have found that performance in Reaper is poorer with this than other apps but did not know why. I also have a Scope DSP system with several synths so what would be the optimal approach with them (again playing/recording in realtime) – Podium’s synchronous mode or Reaper’s anticipative or something else?

bfloyd: 512 should be fine, but then it depends how complex the VSTs you are using are and also how old your system is. It’s really down to trial. I assume you’re using 44.1kHz? You may have already stated, I’m not sure.. If not, you should at least for the time being. Often when I’m sound manipulating I’ll use 96kHz, for clarity, but if I’m just laying down notes or playing real-time (I talk like I do heaps of this when I don’t :lol:) I’ll switch to 44.1kHz.

I’ve used, with an older system and worse sound card, 1024 for latency before. It’s not awful, but that’s also down to opinion. You should still try it, especially with older systems. It may help you.

If you want to test CPU, and numbers of tracks, why don’t you do this (if you haven’t already)? Make one track. Run it through a synth set to a complex patch. Make a quick melody/riff. Check CPU usage while it plays, maybe both in Podium and task manager if you want. Duplicate that track (not sure if you can do that directly; you might need to create a new track and insert VST again – or maybe track templates? I haven’t used these things yet so I’m a little .. out of date :oops:). Copy the MIDI notes but change their octave up or down. Check CPU usage again. Keep duplicating and have a look for yourself what affect on CPU usage it has; you may find that 2 tracks are 40% and 4 are 80%, or you might not. The best way is to try for yourself!

Hell, I’d do just that on my system if I weren’t preparing for a new university semester (orientation week, ugh).

amused: Did you try Reaper in synchronous mode, instead of anticipative, to see if that solved the issue you had with it? I’ve never used Reaper, it just seemed like an obvious question to ask. 😳

@bfloyd6969 wrote:

Ok, I think I finally understand what you’re saying now (yeah, took me a while to grasp this). So you’re saying that right now with 2 tracks playing and my Task Manager cpu reading 40% is mainly due to the graphics on the user interface and that once I start adding more tracks I won’t see the Task Manager cpu rise accordingly (i.e 2 tracks = 40% so 4 tracks = 80% will not happen).

Correct. And the CPU used by the UI will also decrease when more CPU is needed by the audio engine.

So by increasing the Asio buffer may still lower the Podium cpu load? This would be even better to boot 🙂 Is it normal to have buffer setting higher than 512? This is where I am currently set at.

Yes. For each processed ASIO buffer, a certain fixed amount of CPU is used by the host for managing the audio routing etc., before the actual buffer processing starts. This fixed amount of CPU is performed less times per second when you increase the buffer size. Another issue with short buffers is CPU spikes. As an example, say you have an instrument plugin that causes CPU spikes at each note start. If the CPU spike has a duration of 5 ms and your ASIO buffer size is 10 ms, then that spike will read as 50% on the CPU indicator. If your ASIO buffer size is 20 ms, then the spike will read as 25%.

A buffer size of 512 should be fine.

@DFusion wrote:

I don’t know if it is explained somewhere on the net but it is simple math 😉

Thanks for the additional detail. I thought there might be a Knowledge base Microsoft Article link for it as well (perhaps there is).

I like to read up on stuff like this from time to time. 8) Very few technical apsects in Windows are “simple” IMO or maybe more should be 🙂