Someone mentioned this in that ever so popular thread and I was curious to try it out.
If anyone has any suggestions on a windows 11 system with how they have successfully configured everything.
Someone mentioned disabling threads 1 and 0? I am trying with ASIO guard on and off.
What’s the trick here to get rid of spike on low usage projects? Cubase is overall using on this current project… about 20% and of course it still spiking. It’s set to high priority with everything else pretty much set at normal.
It would be best to refer to the original thread on this topic.
That said, I do not know if the information there is still relevant. The primary complaint was the periodic audio glitches.
I am currently up to date with Windows updates (including the new Windows MIDI) and Cubase.
Currently, I am not running Process Lasso and have mostly been playing with MIDI and instrument tracks and have not noticed the problem. However, I am also not taxing the system with lots of audio channels.
There is a LOT of information there, so it would be best to review thoroughly. I may revisit the issue at some point to better understand current behavior. I have not spent any additonal time on this for a while.
There is not much detail about how to use it specifically with Cubase. The tip of disabling core 0 that I found elsewhere seemed only important for Dell systems and some of their drivers or processes and does not make a difference.
I’ve tried various settings and nothing makes much of a difference. So maybe all the vague talk about it is only relevant for very specific scenarios/hardware or only along with other workarounds that might not even be worth it in the long run.
There were a bunch of folks in there that hopefully…maybe will stop by and chime in with some more details and their setups and/or testing.
That is the key point: when using all those hacks, tips and whatnot that are floating around the net, be sure that you have valid and good tests to determine whether a setting really makes a difference (and also be sure to know how to roll it back if it doesn’t help).
I have tried Process Lasso on my Ryzen System and didn’t notice any difference. I think it can be helpful on problematic systems (as the aforementioned Dell with some drivers that cause dpc latency) to prevent dropouts.
If you don’t have DPC latency issues, I don’t think it will make a very noticeable difference regarding the load on the ASIO performance monitor. That is due to the plugins you use and (depending on the project) Cubase’s know problem with distributing plugins and channels across many cores.
As @fese says, it’s really important to measure the results of each change you make.
A while back I ran some tests on Process Lasso with projects I use as benchmarks. With each change I made I compared the before and after results with each project.
I tried hyperthreading on and off (I’m on Intel), e-cores on and off, setting core affinities and dispatching priorities. The end result was that increasing dispatching priority had no effect and all the other changes reduced performance by varying degrees.
The only useful tool I’ve found is ParkControl which allows me to turn off core parking. This actually has shown a measurable effect in reducing interrupt to process latencies which were giving me the occasional dropout on my VSTi machine.
For sure…definitely understood. We are going to each need to weigh out each of our scenarios. Even if we can take a little here and there anecdotally, I think it’s still helpful.
I think we also learn more about our computer systems or the technology we purchased good money for, only to find out its limitations. So it’s a good learning…process
All I have come away with so far is that Cubase could care less about multithreading on or off and that whether ASIO guard is on or off, Process Lasso/windows still does a pretty good job of balancing the load. One thing Cubase does not like is forcing it to one core. It literally stops/hangs and maxes out that single core until you let it breath.
One thing is for sure, those Cubase performance meters do nothing to indicate its actual performance other than actual audio dropouts…or being near it. So, maybe its getting to grips with what is what, instead of assumptions.
These are vague results so far, but Process Lasso is definitely helping to some extent…the plugs that usually hit that performance meter are not as heavy, like ones from Arturia, or oversampling. If the theory is that Cubase does not truly know how to use multicore processing very well compared to Reaper or Bitwig, I am seeing indications of it when I can turn Cubase multi core processing off and see no difference at all from a system perspective. Cubase is still being load balanced across all allowed cores. Even with two or four cores when forced. This goes back to the coming to grips part.
One important thing to understand is the difference between ASIOGuard and the realtime path and their impact on the performance meter. E.g. Activating record or monitor on a track will put that track in the real time path which in turn will let the realtime/peak meter jump higher. This is fine, but just something to be aware of that when doing comparative tests.
A project can run just fine if everything is ASIOguard, but if you activate a track that has a cpu hungry virtual instrument on it and then some more demanding effect plugins in the channel inserts, there is nothing that multicore and threading can do, you will at some point saturate one core (or as close to saturating as realtime audio allows). Then you either need to activate “constrain delay compensation” or increase your buffer size.
Also, Control room plugins are always in the real time path, which most people tend to forget, so that will also have an impact on the peak meter, if you have some plugins there.
Cubase does not like core 0. Highly suggest disabling that core in the always settings. When using that core, overall performance meters get worse in general.
Cubase does not work better with more than 4 actual, non-hyperthreading cores or what nowadays would be “performance” cores. The load may look like its “spreading” across multiple cores with (Cubase)multi-thread enabled in the overall cpu usage, but it does nothing for real-time or peak performance.
I have also noticed that the Realtime and peak performance do not change according to priority…at least in the project I have running/testing.
For anyone with more experienced and knowledgeable in what ASIO guard actually does(besides the obvious in the naming), …does ASIO guard “fight” Process Lasso or vice versa? Is it better to leave both running or one or the other? I am just throwing that question out and might end up answering it myself…eventually.
Using Intel Core i9-14900KS here, windows 11 23H2, 128G RAM.
Whether I include Core 0 or not with Process Lasso, does not seem to make any difference for me. Cubase CPU usage still remains at 20% or slightly above, but never goes beyond that.
I think in order for Cubase to go beyond that, it’s code needs rewriting from the ground up, and I don’t think that’s what the folks at Steinberg are looking forward to…
Yeah…I am thinking because that is a totally different cpu and architecture. I don’t know enough about the newer intel architecture and how windows handles specific cores…besides the P and E basics.
It seems like my Ryzen generation has specific internal priority architecture where process lasso makes small but noticeable difference with excluding core 0…so far.
I am starting to think that those architectures are much better for Cubase in general, right now.
I tend to agree. There is just something “off” with how Cubase is handling all of this power.
I also really wish GPU audio processing continues to evolve because with all this literal power at our disposal, I wish we could utilize it better. GPUs are designed to be very realtime and parallel.
Except that most DSP processing isn’t really parallel in nature, and GPU processing still adds extra latency, it simply doesn’t lend itself to GPU computing as video or image does. Also, there is no real standard for audio processing on GPUs.
A couple of years ago, the company gpu.audio announced that they had solved the problems of processing audio on GPUS and offered a SDK that abstracted away the differences between the GPUs, they even offered some free plugins on their website (unsurprisingly mostly time based effects like reverb or modulations). It didn’t gain much traction in the plugin developer community, as they a) only supported limited GPU models at the beginning an b) it would mean extra investment and effort for relatively little gains.
Couple of years later, there is one plugin actually available to buy with their technology, tow others are listed as “coming soon”, their free plugins seem to be gone and the company seems to focus on the automotive industry.
So I would’t get your hopes up that GPU audio will be coming soon…
They had no issue adapting AI for GPUs when Nvidia needed to sell more. Not that the audio market and profits are comparable to Ai.
And yes, the GPU audio company you speak of is what I was referring to. I was not saying soon…just that it would evolve. If there is a company to do it, it’s Yamaha/Steinberg. Maybe they buy up GPU. audio
Actually, AnalogX with all of its modules runs on the GPU now. I remember trying it out, but it was kind of buggy and in beta. That is the progress I mean.
