Renoise reporting extremely high CPU usage (99%)

So ever since upgrading to Windows 10 64-bit I’ve experienced extremely high CPU usage in Renoise that does not correspond to Windows’ own CPU usage reporting.

Like, 99% in Renoise, and 35% in Windows:

(might not be readable, it says “34.0%” for Renoise, “38%” total for all CPU usage in Task Manager, while Renoise is claiming “98.4%”)

My computer, which is a gaming rig with a Core i7 and 16 gigabytes of RAM, is overclocked, all power throttling in Windows is disabled, and no other applications have this issue.

This high CPU usage in Renoise causes my songs to hitch, stutter, and distort, making it unusable.

Are there any Renoise settings I can change that might fix this issue?

Or anything else I can try that might help?


Could be a couple things.

  1. In Preferences → Audio what do you have under Multi CPU/Core Support?
  2. How many logical cores are there on your i7?

If your CPU has 10 cores but renoise only has access 4 of them, you could see behavior like that.
Renoise thinks it’s near 100% while the Windows only has 4 out of 10 cores on it.

Renoise is set to “8 CPUs” in preferences.

And my CPU (i7 4770K) has 4 cores and 8 threads.

Hrm. Could there be an issue if Renoise thinks it has 8 cores to work with, but really it’s 8 threads?

the 8 threads are also known as logical cores which is what Renoise populates in the dropdown
The 4770K has 4 physical cores and 8 logical cores (the 8 threads)
Renoise picked that up and thats why the dropdown has 1-8 CPUs

Post a screenshot of your task manager displaying CPU utilization per core.
The 38% is aggregate. Lets see what the breakdown per each of the 8 cores.

Certainly. Thanks for the help, by the way.

It wasn’t as absurdly high this time, but it was still really pushing my system (Renoise reported 85% CPU at the peak):

renoise cores

Looks like the OS is able to handle the load but Renoise is reporting near capacity.
The task manager’s take on processor utilization is really disconnected from what Renoise thinks.
In the end what matters is how reliable the audio output is.
The Renoise CPU readout is just a meter and even if it exceeds 100%+, if there’s no audible effect, it doesn’t matter what the meter reads.
Perhaps try driving renoise as hard as you can, load a bunch of heavy plugins.
See if there’s some correlation between audio interruption and the CPU reading.
That way you can get a better sense of what the meter is really telling you.

Can you install latency mon and check for drivers with very high latency? It might very well be outdated drivers.

Here is a video about this issue specifically:

1 Like

Those 2 percentages are not comparable. The value that Renoise returns refers to CPU usage for audio (which depends on your sound card: the “audio CPU usage”), and the value that Windows returns refers to overall CPU usage.

Stop looking at your CPU and look at your sound card to understand this…

Exactly. CPU usage, or in the DAW world also called DSP load (DSP = Digital Signal Processing) is a different value than what Windows says. It’s not just CPU. It’s a mix of CPU load and what your audio interface and its drivers can handle (pre-buffering).

you guys have no clue what you are talking about.
Your audio interface has a simple DAC, the amount of processing it does pales in comparison to the mainboard CPU
Your plugins and sequencing are all handled by your main CPU
Your audio interface does relatively simple DSP, mostly just DAC.
And unless you have a specialty audio board, there’s no “CPU meter” on it.
Komplete Audio, Presonus, Mackie, etc. they all use off the shelf single task DSPs that run at a constant clock.

Renoise uses your main CPU to do all the processing, then pumps the processed samples into your audio interface.

The audio interface uses its “processor” to convert the samples into electrical signals that then drive a speaker through an amplifier.

1 Like

Your reply is a little bit blunt, but correct. The Renoise CPU meter shows the load on the most stressed core, as this is the limiting factor in real world use. It doesn’t matter is 7 threads are at low usage if a plug in is caning one core. Try to make sure all plug ins are updated and that, where applicable, the plugins are set to utilise multi-core processing - for example clicking the Multicore option in Diva broadly halves it’s impact on my CPU metering. Also check that real time processing is set to a lower quality than offline rendering in some plug ins. Try to avoid huge oversampling multipliers in plugins that introduce non-linearities into the processing chain. Use demanding effects on a bus rather than per track.

hmm, doesn’t sound right either.
Whats your source for CPU meter showing most stressed core?

taktik commented on a post from 2012

It’s correct, a VST will be computed by the CPU to process it’s sound in “realtime”. But all the audio signals of of the DAW have to go through the audio interface to be converted from digital to analog signal for the audio output (speakers, headphones, etc). Here the 2 magic words are “Audio Buffers”. That’s what i meant with pre-buffering. You can have the fastest CPU in the universe, but it won’t bring you much, if your audio interface and its drivers have a poor audio buffering. Your Audio interface will convert the digital signal to an analog signal by the DAC. The conversion needs some time. Here comes the audio buffer into play. It will store the incoming signal, until it is converted in “realtime” to the analog signal. If too much “realtime” informations reach the buffer, than it can handle, you will get these famous clicks, crackles, audio gaps, and even CPU overloads. Because if the buffers are full, they can’t load more informations and these infos get lost, the so called “buffer overruns”. If the interface can’t convert the incoming signal fast enough, it will slow down your CPU which you then can see as heavy CPU load, because the CPU now is forced to send it’s infos just as slow as the audio buffers can handle, even if the CPU could handle way more infos in “realtime”. It’s like a cup of water. For example, take a cup with a small hole on the bottom. The cup represents your audio buffer. Constantly fill it with water, (which represents the incoming audio signal). The tempo, how fast the filled water will drain through the hole, represents how fast the buffers can handle the incoming signal. If you now fill in more water than can drain, your cup will spill over and the too much water will get lost. And this will represent the gaps, clicks and crackles. If you now just fill the cup as fast as it can drain through the hole, you have to fill in the water with a slower tempo, which represents the CPU, that will slow down. And that is what you see in a DAW’s CPU/DSP meter as a higher CPU load…
And if you now increase the buffer size, the buffer can handle more infos in realtime. It’s like you now use a bigger cup for the water. You can fill it with more water than before until it spills over, but it takes longer time, which then represents a higher latency…

That answers one of my question I asked a few weeks back about CPU usage.

My setup is a i5-9600k (6cores, no hyperthreading) and a Focusrite 2i2 audiointerfae, apparently that CPU is way too overkill for the audiointerface, who would have thought?
I wonder which audiointerface to get next time, any suggestions?

In most cases it’s not the interface itself. In most cases it’s the poor programmed drivers of the interface. There’re also much other things that can slow down the CPU power. Other devices like slow harddrives or RAM, even the wrong BIOS setup can slow down a system, some bad quality components like the chipset of the mainboard, etc. Even the VSTs themselves can slow down a system, even if they use nearly zero CPU. If you use a bunch of VSTs that just can use one single core, they may use all the same one core and drive it to the limits, which also can raise the CPU meter.

some of what you wrote is accurate, but some isn’t.
There are at least 2 memory buffers, one inside the audio interface itself and one inside the audio interface drivers running on the PC.

Your analogy would be more apt if instead of too much water in the channel there is not enough.
When the main CPU is so overloaded it can’t send enough water to the audio interface.

The processing inside the audio interface is very predictable, just DAC on pre-known rates etc, so buffers are very stable.

On the PC side, Renoise is using the mainboard CPU to process the plugins, effects, etc and then feeds it to the audio interface drivers.

The audio interface requires data at a certain rate and if the mainboard CPU can’t keep up, it interrupts the audio.

audio interface is very simple.
Expensive interfaces used to be required because of ASIO drivers.
But now they are generic.
You can get just as good sound (perhaps better) on a simple Intel HD audio AC’97 with a headphone jack
Or whatever is default on a macbook
I wouldn’t doubt grammy awards were handed out to people producing on default audio interface.


There’s some info on FL studios website about this phenomenon, Renoise probably use the same method of calculating the CPU usage.

From my understanding they should probably relabel CPU to (AUDIO) POWER because from our point of view it’s ludicrous when we see a 50% CPU utilization just to have it stutter or crash.

I had paraphrased from memory, perhaps I should have linked to this. Although I remember reading a different Taktik post as well but I can’t find it now, sorry.

Only @taktik cando here a useful statement. Is it a problem caused by cpu peaks? Or microcode patches (I think those are sideloaded with Windows on boot or efi)? A more sophisticated CPU monitor in Renoise as in Bitwig, a grpah over time, might bring light here.