Engine load

[Steve Moddelmog]

What hardware component is the principal driver of the performance measure "engine load?" CPU? Sound interface? Both? I am maxing it out a lot and trying to figure out what my weak link might be.

[Colin Nicholls]

57 minutes ago, Steve Moddelmog said:

What hardware component is the principal driver of the performance measure "engine load?" CPU? Sound interface? Both?

From the manual:

Quote

The Engine Load value is a percentage of the total time the engine took to process an audio buffer. If it takes 100% or more of the
allotted time, the buffer is processed too late and it will result in audio glitches/distortion. The value in parenthesis represents the
max engine load since the time the engine started.
Engine load is a better metric to help troubleshoot audio glitches during playback since it accounts for other delays in synchronizing
and processing audio workloads beyond what the CPU meters report. It's normal for engine load to be higher than the average CPU
meter value shown.

 

[Colin Nicholls]

Seriously folks, https://bandlab.github.io/cakewalk/docs/Cakewalk Reference Guide.pdf and Ctrl-F

[Steve Moddelmog]

8 minutes ago, Colin Nicholls said:

Seriously folks, https://bandlab.github.io/cakewalk/docs/Cakewalk Reference Guide.pdf and Ctrl-F

Yes, I did read that, but if it answers my question, I don't understand how.  I always look for answers in various places (manual, previous posts, general Googling) before asking questions o a forum.

[Colin Nicholls]

Probably read snarkier than I intended when I wrote it.

[Steve Moddelmog]

Haha, no problem!

[Promidi]

8 hours ago, Steve Moddelmog said:

 I always look for answers in various places (manual, previous posts, general Googling) before asking questions o a forum.

Sometimes it helps to briefly mention where one has tried to find the answer along with the question...... 

Even maybe mention the specific resource and adding....."but I just need help understanding this part.................."

[msmcleod]

The simple answer is everything can affect performance, however for the most part CPU is by far the biggest driver - with CPU speed being the largest factor.  While a greater number of cores can help, due to the serial nature of how plugins / audio mixing are processed, there is almost always going to be one thread/core blocking the rest for at least some of the time.  So the faster the CPU, the quicker it can finish it's processing allowing the next lot of processing to be performed.

Amount of RAM doesn't really make a huge amount of difference, unless you're dealing with large sample libraries.  Of course, there is a minimum amount of RAM you will need to avoid unnecessary paging to hard-disk. The minimum recommended RAM is 16GB, which should be fine for general use. If you are using lots of sample based instruments, 32GB or more can help.   8GB is really not enough unless all you are doing is recording raw audio, and not using any plugins.  Faster RAM will improve performance, but may or may not be noticeable depending on the project.

Hard drive speed shouldn't be an issue unless you have a large audio track count, you use lots of sample based instruments, or you don't have enough RAM.  An SSD is much faster than a standard hard drive.  To give you an example: for me, Omnisphere used to take up to 45 seconds to load a patch from a HDD, which was reduced to less than 2 secs on an SSD.

For the most part, the audio interface should have little if any affect on performance.
 

[Steve Moddelmog]

2 hours ago, msmcleod said:

The simple answer is everything can affect performance, however for the most part CPU is by far the biggest driver - with CPU speed being the largest factor.  While a greater number of cores can help, due to the serial nature of how plugins / audio mixing are processed, there is almost always going to be one thread/core blocking the rest for at least some of the time.  So the faster the CPU, the quicker it can finish it's processing allowing the next lot of processing to be performed.

Amount of RAM doesn't really make a huge amount of difference, unless you're dealing with large sample libraries.  Of course, there is a minimum amount of RAM you will need to avoid unnecessary paging to hard-disk. The minimum recommended RAM is 16GB, which should be fine for general use. If you are using lots of sample based instruments, 32GB or more can help.   8GB is really not enough unless all you are doing is recording raw audio, and not using any plugins.  Faster RAM will improve performance, but may or may not be noticeable depending on the project.

Hard drive speed shouldn't be an issue unless you have a large audio track count, you use lots of sample based instruments, or you don't have enough RAM.  An SSD is much faster than a standard hard drive.  To give you an example: for me, Omnisphere used to take up to 45 seconds to load a patch from a HDD, which was reduced to less than 2 secs on an SSD.

For the most part, the audio interface should have little if any affect on performance.
 

Thanks for your thorough answer.  I figured RAM would not be part of the equation.  Anyway, I have 32 Gb which seems ample, though my prior system had 48.  Hard drive is SSD, though not a particularly fast one.  Not using large sample libraries, so I think it's probably adequate.  My processor is an i7-1165G7 - not spectacular, but seems like it should be up to the job.  I just replaced my 3rd gen 2i2 with Zoom's new UAC-232.  I have been running Sonar / Cakewalk for more than 20 years and have read about / done every tweak imaginable to optimize for music production.

The reason I posted my question is that lately several projects have been stuttering during playback (and occasionally stop playing altogether until restarting CW or the computer).  No dropout message, but I see max engine load as high as 180% and sometimes a lot of late buffers.  All this has happened probably more or less simultaneously with trading out the 2i2 for the UAC-232.  So I thought that might be the problem, it being a new product.  But the same projects that are problematic sometimes play with no problem and max out at, say, 55% max load with no late buffers.  I have an Apogee Duet (the model that was bundled with ProTools and was their first with Windows drivers).  I tried swapping out the UAC-232 for the Apogee and I would say the engine load is generally maybe 10 percentage points lower, but there's so much variability that it's hard to say for sure.  Once or twice it has also gone to >100% max engine load and a lot of late buffers.  Also wondering if some particular plugins are to blame.  I recently started using NI's RC 24 or RC 48 reverbs in virtually every project, and some of those recent projects also have NI's Replika or Replika XT (on not more than one track per project).  Replika has always seemed like a resource hog.

But if the plugins aren't to blame, I guess that leads me back to the CPU?  By the way, one of the first projects I noticed the issue on only had 2 vsti tracks and one audio track.  Any thoughts or suggestions are appreciated.

Edited May 17, 2023 by Steve Moddelmog

[bitflipper]

Given your specs, two VSTis should be well within your system's capabilities. I routinely work projects with literally dozens of VIs, and my system is less powerful than yours.

Your issue may be external to the DAW. While it's processing audio data, the CPU is also busy with background tasks that compete for attention. If some other process is excessively chewing through CPU cycles it'll be almost pointless to optimize the DAW. One category  of potential CPU hogs is overhead from interrupts. A tool exists for getting DPC stats (Deferred Procedure Calls, meaning the software that runs in response to an interrupt), which can help pinpoint the culprit(s).  Hop over to respendence.com and download their free LatencyMon tool. 

[Lord Tim]

I do think a bad audio driver can affect stuff to a degree too. I've had wildly different levels of performance from interface to interface - it's night and day between my Scarlett 18i20 and my old TASCAM 16x08 as far as clicks, pops and low latency goes.

[Billy86]

3 hours ago, msmcleod said:

While a greater number of cores can help, due to the serial nature of how plugins / audio mixing are processed, there is almost always going to be one thread/core blocking the rest for at least some of the time. 

@msmcleod curious… what about plugin load balancing? Does this not create any parallel (as opposed to serial) processing?

Or CPU/system optimization  such as BitSum’s Project Lasso or ParkControl? https://bitsum.com  How (do?) they impact engine load performance? Project Lasso allows you to assign system priorities to applications when they’re running, which I’ve done for CbB. May be my imagination, but my system seems to be more stable and robust since installing a couple months ago.
Example: currently finishing a dense rock project with 90 (gulp!) plugins — at least when exporting my mix a toast notification says ‘flushing 90 plugins’ when going about its business. 

[John Vere]

I’ll have to agree with @Lord Tim. Audio interface drivers can make a difference and I was a bit surprised at Marks comment. 
I have 5 audio interfaces on hand right now. My latest is a Motu M4. I had been running using 128 as my buffer with both a Tascam and a Scarlett interface. The minute I started using the Motu I would get occasional static. Not drop outs but definitely the audio sucked. I now have to use 256 and even higher.  
Out of curiosity a few weeks ago when this happened I turned off the Motu and turned on the Scarlett 6i6. I set it for 128 and worked all day with out any audio issues. 
it’s old and missing a few features the Motu has but the only difference must be in the driver.  I keep hoping a driver update will fix it.
The other thing I wonder about is USB power? The Tascam and Scarlett use wall warts.  The Motu is bus powered. At Motu supports advice I purchased. Dedicated USB PCIe card which improved the static issues somewhat but not 100%. 
When the OP said Zoom I went “ Oh, oh!  “ Been many complaints about those drivers in the past. 
I think some companies like Motu are very oriented towards Mac OS or that interfaces that don’t come with proper power supply’s do not perform as well as the ones that do. 
 

[msmcleod]

12 minutes ago, Billy86 said:

@msmcleod curious… what about plugin load balancing? Does this not create any parallel (as opposed to serial) processing?

Only to an certain extent - it totally depends on your signal path.

For example, if I've got seven tracks all doing their own processing on their own threads, but they are then routed to a bus with a compressor on it, that compressor cannot process anything until all seven tracks have done their own processing first.

It's like having 8 employees in a factory - 7 of them are producing widgets, and the 8th one puts them in a box at the end.  The 7 employees are working in parallel, but the 8th employee can't box them until all of widgets are ready.

Likewise, if you've got 4 effects in a track's effects bin they have to be processed serially, as the output of each one is fed to the input of the next.

However, the FX bin of multiple track effects can be processed in parallel - i.e. the effects in track 1  can be processed at the same time as the effects in track 2 because they're not dependent on one another.

The other thing to bear in mind with plugin load balancing, is that sometimes the task switching between threads can outweigh the benefit. 

[msmcleod]

1 hour ago, Lord Tim said:

I do think a bad audio driver can affect stuff to a degree too. I've had wildly different levels of performance from interface to interface - it's night and day between my Scarlett 18i20 and my old TASCAM 16x08 as far as clicks, pops and low latency goes.

 

1 minute ago, John Vere said:

I’ll have to agree with @Lord Tim. Audio interface drivers can make a difference and I was a bit surprised at Marks comment. 
I have 5 audio interfaces on hand right now. My latest is a Motu M4. I had been running using 128 as my buffer with both a Tascam and a Scarlett interface. The minute I started using the Motu I would get occasional static. Not drop outs but definitely the audio sucked. I now have to use 256 and even higher.  
Out of curiosity a few weeks ago when this happened I turned off the Motu and turned on the Scarlett 6i6. I set it for 128 and worked all day with out any audio issues. 
it’s old and missing a few features the Motu has but the only difference must be in the driver.  I keep hoping a driver update will fix it.
The other thing I wonder about is USB power? The Tascam and Scarlett use wall warts.  The Motu is bus powered. At Motu supports advice I purchased. Dedicated USB PCIe card which improved the static issues somewhat but not 100%. 
When the OP said Zoom I went “ Oh, oh!  “ Been many complaints about those drivers in the past. 
I think some companies like Motu are very oriented towards Mac OS or that interfaces that don’t come with proper power supply’s do not perform as well as the ones that do. 
 

I didn't count latency as a performance issue per se, but I can see how it could be seen as such. 

The latency does differ between interfaces even though the buffer size could be the same.

The bottom line though, is that it's up to the CPU to cook the buffers in time.  Increasing the buffer size (and therefore the latency time) gives the CPU more time to cook the buffers. Cracks & pops are a symptom of the latency time being too low for the CPU to catch up with, but not enough to drop out.
 

[John Vere]

For me the latency is not noticeable due to using direct monitoring.  But my issues makes me think it’s important to write an audio driver that is efficient for the OS to communicate with.
I was thinking of ordering a USB-C PCI card to see if that would solve possible power supply issues.  

[Steve Moddelmog]

7 hours ago, bitflipper said:

Given your specs, two VSTis should be well within your system's capabilities. I routinely work projects with literally dozens of VIs, and my system is less powerful than yours.

Your issue may be external to the DAW. While it's processing audio data, the CPU is also busy with background tasks that compete for attention. If some other process is excessively chewing through CPU cycles it'll be almost pointless to optimize the DAW. One category  of potential CPU hogs is overhead from interrupts. A tool exists for getting DPC stats (Deferred Procedure Calls, meaning the software that runs in response to an interrupt), which can help pinpoint the culprit(s).  Hop over to respendence.com and download their free LatencyMon tool. 

I downloaded the tool and have run it numerous times.  Every time, all looks fine at first, but it eventually (from 30 seconds to 2 minutes in) gives me the message about "having trouble handling real-time audio" and simultaneously (I think) flags ACPI.sys as having the highest reported ISR and DPC routine execution times.  It makes suggestions about Power Management (I'm really about 100% sure I have power settings at their most "generous" for every component) and tells me to check for BIOS updates (BIOS just updated less than a month ago).  Any insights or suggestions are welcome.

Incidentally (or maybe not so incidental), the sound is not always affected (to my ears, anyway) when the max engine load exceeds 100% and there are a few late buffers).  But when the sound is poor, the max load is always reported at >100% and there are more than a few late buffers.

Thanks to all who have offered their thoughts and ideas.

[Bruno de Souza Lino]

11 hours ago, msmcleod said:

with CPU speed being the largest factor.

What about instructions per clock?

[John Vere]

With the Resplendence tool you can generally ignore some of what it tries to tell you. I think it always says the same thing no matter what. That APCI looks like the issue however.   And sometimes you need to run it for long time. If it tells you there's an issue it's telling truth so you need to start looking for what is doing that. I always open Task manager / performance tab and look at what's going on with Cakewalk running a big project. 

 

Edited May 18, 2023 by John Vere

[bitflipper]

I've seen complaints about ACPI.sys having excessive DPC latency before. Usually on laptops, usually having something to do with power settings. You might try some different power schemes, just to see if it makes any difference. Make sure that sleep mode is completely disabled. I've always used the "High Performance" power preset, which, iirc, disables sleep mode. Also go into the Advanced power settings, expand the USB Settings category and verify that USB suspend is disabled (assuming your interface is connected via USB).

ACPI does more than just power management, though. (Well, technically ACPI doesn't do anything on its own, as it's a driver that interfaces with your BIOS. The idea is that ACPI.sys lets you change certain BIOS settings directly from Windows that in the old days would have required booting into the BIOS.) It might be worth booting into the BIOS and poking around in there. It may allow you to disable ACPI.