DSP Robotics Support

Dear all,

A general question for display Vs. CPU, which I believe should interest many users...
The question is related to high CPU usage when live display is used.

As an example, I had built a very simple module (attached: Display_test) unit, which is made by two FFT displays (simply taken from S.M.) and two amplitude bars, each for a single channel.
No processing is done, so it is a pure visualizer.

When I look at F.S. CPU meter (while music is playing and display is reflecting this) - the reading is 0.7% (with or without display running).
Exporting is to Cubase 5.1 - the Cubase meter shows '1%' cpu.

However, when measuring CPU via windows 7 (ctrl+alt+delete --> task manager --> resource monitor) the readins is 22% while display is running (or at bypass i.e. frozen) and a complete zero once removed (music is playing via DAW).

My question is double:
1. Why is there such a difference between 'real CPU' reading and Cubase/FS CPU measurement?
2. How to lower CPU usage for live display (FFT, amplitude bar, etc.)?

Thanks,
Rocko

Rocko wrote:1. Why is there such a difference between 'real CPU' reading and Cubase/FS CPU measurement?

Because CPU meters in daws and flowstone measure CPU used for stream calculations. Green is omitted, as it will simply not be calculated if there is not enough time (for example GUI freezes during very high CPU loads). However, Task Manager will also show the CPU usage of Green.

Hi,

Thanks for the clear answer.

so, for next stage, do you have any advice of how to lower CPU consumption of real time screen redraws, like the mentioned FFT and 'amplitude bar'?

Any written material on tips to lower graphical redraws and bring CPU down (22% is not acceptable, right?)

Thanks,
Rocko

redraw area instead of redraw full view may decrease the CPU consumption a lot. also, don't use 100ticker - it is pointless. Make sure you minimize the number of computations triggered by the ticker.

Hi,

Thanks for this:

redraw area instead of redraw full view may decrease the CPU consumption a lot. also, don't use 100ticker - it is pointless. Make sure you minimize the number of computations triggered by the ticker.

However, if I want to create an EQ with an FFT at the background of screen (as an example). In this case the 'redraw' area is very big, even though the line to be redrawn is slim (not many pixels).
Moreover, the difference between two consecutive lines is small.

Is there a way to lower CPU consumtpion in such a scenario?
Trying to think of a 'dynamic area redraw' function or something...

Moreover, thinking of a way for cheaper FFT calculation as well...

Rocko

Lower tick, less triggers on the go. You don't need tick25 for that. And you need to pay attention on multiple triggers on large arrays. Basically, if you don't use editboxes (refreshing in edit state isn't working correctly), you could use common redraw/tick area, without bothering with individual redraws. This way - the gui with displays will behave slightly more coherent, because all elements are refreshed at once.

tester wrote:Lower tick, less triggers on the go. You don't need tick25 for that. And you need to pay attention on multiple triggers on large arrays. Basically, if you don't use editboxes (refreshing in edit state isn't working correctly), you could use common redraw/tick area, without bothering with individual redraws. This way - the gui with displays will behave slightly more coherent, because all elements are refreshed at once.

this is a very good post!

Rocko wrote:Is there a way to lower CPU consumtpion in such a scenario?Trying to think of a 'dynamic area redraw' function or something...

it is possible, but calculating the dynamic area /areas may actually increase CPU. the View is redrawn in form of rectangles, but the rectangle containing the line is in most cases big (ranging from very low values on low& high end with big values in mids usually)

Rocko wrote:Moreover, thinking of a way for cheaper FFT calculation as well...

FFT is the cheapest way to do it. The thing that actually takes so much CPU is updating the arrays, as Tester mentioned. Try to minimize the no. of triggers that they are updated with. Also use trigger divide prim to lower the frequency of triggers. 12triggers/second is more than enough.

One thing worth to mention if you play with FFT stock stuff here. It appears, that maximum stream-to-green resolution of stock prims is 16kpts. But... In essence, if your goal is not to do the precise peak finding (I'm not not refering to pitch detection/following here), but just a visualization of spectral bands to give a brief picture for an EQ - you can use even lower arrays, like 8kpts or 4kpts. This should give you some speed.

Hi,

Following your recommendations, ill run some experiments and update the forum with results. Hopefully in a few days due to (other) work load.

Thanks,
Rocko

Is this related to the way a Flowstone schematic with lots of draws will drag down the whole screen's redraw rate in the DAW?