Process Lasso and Cubase

[DaveB]

I have to start by saying that I wish I had discovered this program MUCH sooner!

I have done a fair amount of testing to try to get later versions of Windows (specifically 10 and 11) to work reliably with later versions of Cubase (11, 12, and 13). I've done countless web searches and reading. I had gotten discouraged enough with my general-purpose machine having issues that I made the just to a newer machine with mostly Cubase loaded.

While the new machine was performing pretty well, I was still getting random audio dropouts or glitches and to say it was getting frustrating would be an understatement.

I was honestly losing track of all the "try this" tweaks and trying to keep track of them!

Ultimately, just installing and running Program Lasso, vastly improved but did not totally solve the issues. With a few additional changes to the configuration, I now have a usable Cubase on all scenarios I'm using.

First the machines:
General-purpose Asus Prime Z490-A with Intel i9-10900K 64GB Corsair DDR4 Windows 11 AMI BIOS v2701
Media MSI MAG Z790 Tomahawk WIFI (MS-7D91) with Intel i9-14900K 64GB G.Skill Dual-boot (Windows 10/11) AMI BIOS vH.90.

I've reverted all the BIOS (try this!) tweaks back to defaults.

Here's the settings I'm currently using:

[Jeremy Collake]

Nice! Thank you for sharing! I have no doubt this will be useful to other Cubase users.

[DaveB]

At one point I was having noticeable audio glitches when audiodg.exe was switching context to another CPU. It appears that the CPU Affinity for audiodg.exe is not required. The jury is still out, but preliminary tests seem it's not needed.

[DaveB]

Two changes from above:

1. Changed the high performance mode to "Bitsum Highest Performance". I think I had high configured the same way and was having some issues with the Bitsum mode but it appears to be working now.
2. Added Park Control and disable CPU parking in Bitsum Highest Performance.

Note: I am still seeing Cubase issues when running Cubase and LatencyMon simultaneously. However, LatencyMon run alone showed that parking the CPUs improved the latency results.

Note: I was stress testing Cubase and it did not seem to benefit from parked cores because the cores were already operating near maximum. Disabling parking did not seem to hamper a fully loaded Cubase, but could potentially impact projects using less CPU resources. Since it seems to have no impact on a loaded Cubase, I'm disabling parking in Bitsum Highest Performance and leaving parking enabled in Balanced.

[DaveB]

I made a few other changes that seemed to benefit latency reported by LatencyMon, but I did not see notable changes to Cubase responsiveness or process load. I made these changes because allegedly some of the latency reports seem to be caused by other tasks/threads, rather than being themselves the cause.

It appears that some OS tasks reporting latency tend to run on CPU 0/1 (hyperthreading enabled, so core 0). This appears consistent with already proven improvements by moving audiodg.exe off of CPU 0/1. Initially I configured CPU affinity for audiodg.exe to CPU 2. After noting additional issues, I have changed the affinity of multiple audio tasks to use ONLY P-cores and NOT CPU 0/1. This improved some latency reported by LatencyMon while seemingly no impact on Cubase.

Essentially, I changed the affinity of Audiosrv and AudioEndpointBuilder to CPU 2-19 (for 10900K).

I'm not looking to invest enough time in this to accumulate a Masters thesis or PHD dissertation. I've already spent a lot of time NOT doing Cubase tasks to get a decent Cubase operation! That said, I would like to reiterate that I now have a dedicated machine with dual-boot (Windows 10/Windows 11) with multiple versions of Cubase (11, 12, 13) installed, along with Wavelab and SpectaLayers and a few other things like LatencyMon, Process Lasso, etc.

Note that this provides a test ground with a fresh install of Windows 10 and 11 that run on literally the same hardware! I can quite literally see a significant difference in DPC latency and execution times between the same Cubase versions on either Windows 10 and 11. There are clear indications that either Windows itself, or Windows 11 drivers are causing increased latency.

I'm willing to try a few things if there are some suggestions to assist in identifying issues. I just don't want to get buried doing things that regression testers should be getting paid to do.

I am NOT an expert in the Windows scheduler! That said, I am a retired software engineer with significant experience in embedded programming, primarily in cooperative multitasking (vxWorks, OpenRTOS) and am well aware of the impacts of  interrupts, process/task priorities, etc. Trying to do near real-time tasks on a preemptive OS is not trivial. That said, people whose job is development on these platforms SHOULD have a basic understanding of what the critical processes are, and should be able to provide SOME guidance isolating problematic tasks to dedicated resources and/or establishing appropriate priorities such that these critical OS tasks get the chance to do their job, while simultaneously allowing enough resources for audio processing.

Sorry this is getting a bit long, but I also wanted to reiterate that attempting to run LatencyMon and Cubase at the same time, is CAUSING problems with Cubase (most likely buffer underruns). My compromise so far has been to attempt to optimize what LatencyMon is reporting, then close LatencyMon and test with Cubase. I have not had the desire to start down another path of trying to get these two programs to "play nice" together.

I am thankful that Process Lasso has enabled me to get a usable Cubase, but I have underlying concerns about what these "fixes" might be causing elsewhere in the system.

Question:

How likely are the changes I've made so far, to cause issues with the Windows scheduler apart from Cubase?

[Jeremy Collake]

It seems unlikely to me that any of the adjustments you've made have appreciable impacts to the rest of the system.

It is interesting that LatencyMon's active presence was causing performance issues with Cubase. We've not heard of that before, though it's certainly possible, especially if your system is on the brink of inadequate real-time responsiveness.

Good luck! As you alluded to, it is a hard battle you're fighting, and we don't have all the answers.

[DaveB]

It seems unlikely to me that any of the adjustments you've made have appreciable impacts to the rest of the system.

It is interesting that LatencyMon's active presence was causing performance issues with Cubase. We've not heard of that before, though it's certainly possible, especially if your system is on the brink of inadequate real-time responsiveness.

Good luck! As you alluded to, it is a hard battle you're fighting, and we don't have all the answers.

Thanks!

Something I would find incredibly interesting would be to isolate portions of the Windows OS to a subset of cores, and subsequently, dedicating cores to the more demanding application code.

Beyond that, I don't have nearly enough insight into how Windows manages memory and caches to fully understand how to get into that level of system tuning.

My BIOS provides the capability to disable hyperthreading on individual physical cores. It is not clear to me that the overhead of managing hyperthreading causes more issues than disabling the feature that should allow more threads to be processed, however it does seem possible.

Another question(s):

Is there a simple way to set up some generic rules that (for example) I can isolate things I determine are Cubase/audio related and an inverse rule assigning the remaining cores to everything else?

Would the Windows OS honor such an arrangement or constantly be trying to manage the resources?

It would seem that this could assure that tweaking priorities will not starve the OS of needed resources as they are isolated on their own core(s).

I get that in DAW processing, there have always been limits. That's why things like "track freezing" existed, and those features I will still use as needed. It's just odd that a CPU that's got more cores and more memory would have more issues getting the work done. I mean, my old 4 core machines were able to run with hyperthreading until the cores just didn't have enough cycles to do more.

Sorry if I'm getting a bit off topic!

[Jeremy Collake]

Something I would find incredibly interesting would be to isolate portions of the Windows OS to a subset of cores, and subsequently, dedicating cores to the more demanding application code.

As of Process Lasso v12.5.0.7 BETA, you can experiment with the new System Reserved CPU Sets tool, in the 'Options / Tools' submenu.

This will do exactly what you want: keep system threads off specific CPU cores, leaving them always available for applications. After defining the system reserved CPU sets, you can then create the inverse CPU affinity rule(s) for your real-time apps.

In this build, it only works for Windows 11, but Windows 10 support will come before the final release.

You can enter the beta channel by checking menu item 'Updates / Include Beta'.

Certainly, you can alternatively create CPU affinity rules that accomplish the same thing, and Windows will honor them. So long as they aren't excessively restrictive, there won't be any problems.

If you try it, let us know how it goes!

[DaveB]

Cool! I may give it a try on one of my machines.

[DaveB]

I loaded the BETA to give this a try. I found the setting under Options/Tools/System Reserved CPU Sets. I first tried setting CPU cores 0-3 and was asked to reboot.

After the reboot, I could see no indication that tasks listed as user SYSTEM were restricted in any way.

I see no new rule in the Rules column and no change to the CPU Affinity for the same tasks. I DO see a rule to omit from ProBalance, just as before.

Interestingly, the % CPU bars show no activity on cores 0-3. If I look in Resource Monitor, all tasks appear to be CPU 0. Though I do see activity on the CPU graphs, primarily on cores 4-7.

I'll experiment a bit more.

[DaveB]

I'm still running the BETA, but removed the rule for system cpu sets.

Resource monitor still lists most everything running on CPU 0 in the table data, but the graphs indicate activity on cores 0-3 that it did not with the system cpu sets rule in place.

Process Lasso shows activity on cores 0-3 with the rule removed, where it did not with the rule in place. It seems almost as if the assigned cores to system cpu sets is reserving those cores but failing to assign the proper affinity range to the tasks to run on those cores.

Any suggestions?

[DaveB]

Note: On rereading your post about this, I apparently misunderstood the implications. I though I was restricting SYSTEM to specific cores but based on your description, I am actually restricting system from those cores.

However, given that, I do not see anything running on those reserved cores even though processes are marked with affinity 0-19. I'm not sure I'm understanding how this actually works.

In order to actually USE the reserved cores, do I then create CPU set(s) to assign the process to the reserved cores?

I this feature overriding the CPU Affinity settings? If so, I don't see the evidence in the GUI.

[Jeremy Collake]

Correct. Since System Reserved CPU Sets is a Windows registry setting, it is not reflected by any rules in the Process Lasso GUI. Your observations indicate that the feature is working. We'll be considering how to better indicate in the GUI that a System Reserved CPU Sets is in place.

I think you are misinterpreting the CPU column of Resource Monitor list. That is an integer representing the % CPU load, not the CPU index assigned to the processes.

I found that you are correct that applications will not make use of the reserved CPU cores, even with a CPU affinity or CPU sets rule. It may be this feature is only useful when combined with interrupt affinity policies for device interrupts, which is not yet supported by Process Lasso.

Therefore, the feature may not be useful to you. Apologies for the head fake! We had this addition staged, and it seemed like a good time to experiment with it.

I recommend you return to your previous plan of inverse affinity rules, one for your real-time apps, and one for everything else.
 

[DaveB]

Thanks again!

Makes sense.

A rule that could assign CPU Affinity based on the "User" column would make my life easier.

Added:

I actually did try matching against user = "SYSTEM" and it did attempt to change affinity but was getting ERROR 62 Unable to set affinity (or similar wording).

[Jeremy Collake]

I actually did try matching against user = "SYSTEM" and it did attempt to change affinity but was getting ERROR 62 Unable to set affinity (or similar wording).

That will occur on a few of the protected system processes. You can ignore the error, if it isn't flooding the log, which it may be if you have 'Options / Forced Mode' enabled. In that case, I recommend more selective CPU affinity rules.

We're certainly always working to make the product easier to use. Thanks for the feedback!