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.
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.
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.
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.
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.
Also remember that the Windows CPU value also reflects the graphics processing of the Renoise GUI (in this case), unlike other programs, which take advantage of the performance of the graphics card.
So it is advisable not to confuse the Renoise CPU value, which refers to audio processing, which probably refers to the higher value of a core (the core selected), with the Windows CPU value, which will reflect practically all Renoise processing as middle value of all the cores (all the processing of everything).
If someone wants to keep Renoise’s CPU value low (this “current audio CPU usage”), just set the Sample Rate low and the Latency (ms) high, inside Renoise: Preferences/Audio… These values depend on the capacity of the sound card used.
To understand it, quick explanation, the CPU (its threads) must process data in cycles and send it to the sound card. If the CPU does not have time to process all the necessary information per cycle because these sample rate and latency values are not set correctly, there will be loss of information, crackles, immediately after displaying a very high Renoise CPU value.
Therefore in Renoise it is better to have a very powerful CPU (because the audio and much of the graphics processing goes through it), the more powerful the better, and also a minimally decent sound card.
CPU (example 4 Cores with 8 Threads):
Core 1 → % audio CPU usage 1
Core 2 → % audio CPU usage 2
Core 3 → % audio CPU usage 3
Core 4 → % audio CPU usage 4
Core 5 → % audio CPU usage 5
Core 6 → % audio CPU usage 6
Core 7 → % audio CPU usage 7
Core 8 → % audio CPU usage 8
Actually, this value refers to the “thread”, not the “core”.
Sample Rate: Select the Sample Rate for playback. All internal audio processing in Renoise will be done at this rate. The higher the Sample Rate, the more detailed the results will be, but also the more CPU power will be used.
Latency:(DirectSound only) Set the buffer size affecting overall latency. Higher numbers will reduce the possibility of crackling sound at high CPU usage, but will also cause more latency (the time it takes the sound from Renoise to reach an output and be heard).
Use hardware buffers:(DirectSound only) This option may speed up playback processing a bit, but only some soundcards support this. If you enable this option, then experiment with recording in the Sampler before deciding to use it permanently, as it may cause issues. If you experience strange results then disable this function.
Limit to stereo in/out:(ASIO only) If you have a multi-IO soundcard, you can disable all inputs and outputs except for the main stereo pair. This may lead to better performance when you don’t need the other channels.