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.
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.
Concerning VST:
Some VST push the CPU to 10-15% sometimes, although there’s not one sound playing.
This is why in some DAWs it is called “DSP” meter.
Sorry to hear your sound is glitching due to cpu.
Perhaps there are some windows settings that might help;
these are some speaker properties settings that could be
tweaked easily to try to see if some improvement can be made:
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”.
More info:
- 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.
Needless. It is only necessary to visit the Renoise Preferences / Audio section and configure the values there.
Thought it might affect the ‘Timeslicing’; but okay, good to know!
Also noticed, 4.7 gigs of Memory seems pretty high for renoise and your overall RAM usage is high.
Below is a shot of the RAM Renoise is consuming on my system with a song loaded:
Perhaps it is a plugin causing the problem, you might be able to do something with the song
to try to identify the ‘memory hog’, it might help.
I also have trouble with this cpu thing.
I got a MacBook Pro mid 2017. not the worlds fastest computer. but ok for Renoise 3.3.
when I upgraded to Renoise 3.4 i could feel something was wrong when running the 3.3 projects in 3.4.
whay to much cpu usage. computer heating up over nothing.
sometimes it heats up just launching the app