CPU Under-utilization?

[TheRyGuy]

Specs:

CPU: Intel Core i9-9900K

RAM: 16 GB 3000MHz

Storage: Intel 660p, Corsair MX500, Seagate 3 TB 7200RPM

OS: W10 64-bit v1903

 

I export songs to the .WAV format, do a further mix with a plugin, and do another export to .MP3.

When exporting to .WAV, CPU usage goes to around 50%-60%. Understandable, due to the plugins.

When exporting to .MP3 with a mastering plugin (iZotope Ozone 7), CPU usage goes to around 13%. 

Disk usage doesn't go above 0% in either scenario.

 

Are there settings that further utilize the power of my system or is this a limitation of SONAR?

Edited October 7, 2019 by TheRyGuy

[msmcleod]

Its probably more to do with the limitations of VSTi's.

Although plugin load balancing is available for VST effects, VSTi's will only use multiple cores if they've been specifically coded to do so. 

This means that if you've got a multi-timbral VSTi using only one hyperthread, it'll only show up as using 6% of the CPU on a i9-9900K - even though that particular hyperthread is running at 100%.

There's only so much you can do with parallel processing / multi-processing, and even when you can do it you can quickly get in to diminished returns due to synchronisation of the processes actually taking up more CPU than doing the work itself.

 

[lmu2002]

I was wondering this my self too. Why doesn't Cakewalk rendering utilize cpu usage to the max (vs video rendering). It does use all the cores and threads when rendering a full mix (when monitoring with HWmonitor). But only around 50% average usage.

[scook]

This still holds true (from http://forum.cakewalk.com/FindPost/3286635) Noel wrote

Quote

There are a few probable causes for bounces not using full cpu.
 
- Some plugin is throttling the processing speed. Even a single plugin can slow down the bounce since the rest of the system will wait for it.
- You are running at low latency. Increasing the buffer size can speed up bounces. There is in fact a config variable to set the bounce buffer size in Preferences | Audio | Configuration File, called BounceBufSizeMsec that allows you to have a higher bounce buffer size.
- Bounce is gated by your hard disk speed. i.e processing can only proceed as fast as your hard disk can write the bounced data.
- If you have compression like MP3 that is applied at the final stage so only one core will handle the compression while others wait.

 

[Gswitz]

 

This is me looking at cpu in cakewalk.

[Panu Pentikäinen]

As msmcleod said, some plugins throttle down speed and there's not much what Cakewalk can do for it.
I have i9-9900k system too, and CPU usage is around 40% when exporting mixes.

[lmu2002]

Great video Gswitz! It feels crazy one track or even plugin can throttle the whole process. Thinking of a 5min song where cpu shows 10% when playing it back, but it takes the same 5mins to render . Maybe this gets a proper remedy in the future.

[StarTekh]

Theryguy : tell me about your motherboard and are you using a 4x nvme ?

 

[mettelus]

The weakest link will always throttle the entire process, since the end result is an assembly. Think of it like the output audio buffer, but faster; a snare track done in .5 seconds is meaningless if not in the context of the output.

You are only going to see max CPU on benchmarks, video rendering, and encryption for the most part. Having a car that does 200mph is meaningless in rush hour traffic; you can only go as fast as the person in front of you.

[Noel Borthwick]

@Gswitz in your one track test with lots of plugins you will see much higher CPU loading and thereby faster speed if you turn on plug-in load balancing.
That is our patented load balancing designed to handle cases with tracks containing many plugins by parallelizing the load on the track. However even that gives me about a 3X boost but not full CPU loading. There are several complex factors involved in balancing loads when bouncing including plugins throttling as well as disk load bottlenecks. I spent a lot of time experimenting with optimizations in this area some months ago and got some benefits. However I ran into plug-in compatibility issues so decided to shelve it. 

The engine is designed more for streaming real time audio rather than processing offline audio so there are some bottlenecks that are imposed because of that.
There is definitely still room for improvement.

[lmu2002]

On 10/8/2019 at 8:35 AM, Noel Borthwick said:

@Gswitz in your one track test with lots of plugins you will see much higher CPU loading and thereby faster speed if you turn on plug-in load balancing.
That is our patented load balancing designed to handle cases with tracks containing many plugins by parallelizing the load on the track.

I started looking into this plug-in load balancing and discovered that I can run my soundcard with much lower buffer size (=lower latency) when it's turned off. I run some tests with a full 32 track mix with lots of plugins/vstis. When the balancing is on, I eventually get buzz/peep audio engine errors when going below 128 buffer size. When off, it runs smoothly with 64 but obviously taxing the first cpu core heavily. 32 buffer starts producing audible cracks but it runs anyhow (not printing the cracks on exporting though). With 32 buffer size the export takes 5-6 times longer than with a 512 buffer size but still utilizes the cpu much harder (core #6 running clearly hottest on my cpu). So no gains there for exporting.

As my work flow is such that I mix while still recording and writing, I find unchecking the balance load option very useful at a later stage when the project is heavily laden with plugins already, and I can happily record stuff with a low latency with bells and whistles running. I have always had the plug-in load balancing on and never payed a thought for it. However, I'm not sure how much sound card specific this issue might be. But I think it's worth experimenting and see if you can benefit from this like I do.

Edited October 17, 2019 by lmu2002

[Noel Borthwick]

Load balancing is not designed to improve latency. It requires at least 128-256 samples to function.  While tracking at low latency its best to leave it off. Its more intended to use while mixing when you have lots of expensive plugins and don't require about low latency, esp in the case where some tracks or buses have many plugins in series, as is often the case when mastering.

[lmu2002]

4 hours ago, Noel Borthwick said:

Load balancing is not designed to improve latency. It requires at least 128-256 samples to function.  While tracking at low latency its best to leave it off. Its more intended to use while mixing when you have lots of expensive plugins and don't require about low latency, esp in the case where some tracks or buses have many plugins in series, as is often the case when mastering.

Exactly my thoughts! I think I will now leave it off completely and just adjust buffer size as required. I  believe lighter powered cpus/systems benefits more of this function. Or very heavy projects.