Cubase 12, frustrated again, this time "checking licenses" forever? <sigh>

[Milkman]

Its been a rocky 3 or 4 years for me and my cubase 10, 11, and now 12 license.

It all started with the hyperthreading + power management + multimedia multithreading issue cubase had for many years, which was not consistent platform by platform. Steinberg did not provide a list of QA'ed platforms that worked best, and they refused to. Technically the multicore issue has existed since 2002 when the original Core2Duo came out. Steinberg says "turn on ASIO Guard!!!!11" for everything, and this doesnt work.

Then I was fortunate enough to build a new system, and that 24 core system (Z690 chipset, 12900KF) does not suffer the issue at all. Yay! No more steinberg support! 6 months of perfect audio production! BLISS!!

Then, last week I had a power failure during a C12 session and when it came back windows audio was broken. C12 would show high internal load on a totally blank project, and real CPU load would show 10% all the time. "Checking licenses / projected object server." stuck in task list. (others on the steinberg forums also see this.) All ASIO devices were doing this. After hours of troubleshooting without any help from steinberg, I rebuilt windows10 and the issue was 100% gone.

Then, during.... the install of one synth, C12 crashed again during the license activation of the synth. When I restarted it, it had the exact same high CPU issue, and I was once again unable to resolve that issue even after reinstalling windows audio, focusrite audio, USB bus drivers, etc etc.

Anyone else... seeing any "checking licenses" process under their C12 process that eats about 6-10% CPU all the time? Anyone have any experience with this, recovering from it without rebuild, or any other info? Exhausted over here.

[Spin Boyz]

This may have something to do with it. https://helpcenter.steinberg.de/hc/en-u ... cture-CPUs
I'm using C11 with a 12900K cpu and have similar issues.

[Milkman]

Thanks for the reply. While this touches some of the same topics as my issue, this doesnt quite fit and is related to the hyperthreading/multicore (internal ASIO overload, real CPU use is low) issue that I have also been dealing with for the last 3 years(mentioned above). I had that issue for the better part of 3 years on my other i7 7800x / x299 based system, and I worked around it. (disabled power management, speedstep, etc, and locked CPU at 4.00ghz).

The machine Ive built today does not suffer from that issue at all, and after a rebuild everything is 100% perfect.

This issue can easily be reproduced by powering off a windows 10 PC without shutting down while cubase 12 is running. Something cubase does corrupts something core to its own licensing service, core windows audio, or something(I keep reaching out to steinberg to get some dev/QA support, but they are extremely unhelpful and extremely slow.)

System is working perfectly again after a full rebuild, but I do not trust cubase one bit since this issue has been discovered and I wanted to chat with others about it. The thread on steinberg's site has brand managers in it telling users "oh this is just your task manager not updating. You need to refresh your task manager", so I thought I would try to have normal conversation about this here and elsewhere. ; )

[Milkman]

By the way, the link in your comment is to a page in which steinberg - *again* - is shifting the blame to the entire industry around them rather than taking any steps toward a better way of handling hyperthreading and power management.

They now claim, lol, that all the 10xxxK or F CPUs are no longer recommended for cubase because of the SAME issue that has plagued them for close to 20 years now. Each time this or a similar excuse is made, and they have once again said "this is a problem for not just us, and so we will wait for the industry to update itself for a fix."

No other DAW has this issue. I just tested Live, FL Studio, and Bitwig, and none of these problems exist on my 10900KF, Z690, 32GB DDR5 system. No games have any issues with process scheduling. Nothing on this system has a single problem BUT cubase, and its been that way on my last 3 systems, since windows 7.

This is Steinberg blaming THE WHOLE ECOSYSTEM, including Intel, Microsoft, Nvidia, AMD, etc, on THEIR OWN inability to workaround multicore, multithreaded audio rendering. They should simply admit by now they will NEVER support virtual cores, or that they will have to develop their own hardware platform to make it work. lol

[Atlatnesiti]

Never had this issue on Mac, but to be honest I still prefer the “old school” dongle over the new online verification process.
I wish that Steinberg would give us an option to choose

[pixel85]

Yikes! Looks like I did good by moving to AMD a few years ago.
But even on Intel I didn't had such problems. Now with Intel Outside, Cubase crashed a few times during plugins scanning but it didn't affected behaviour/ performance in any way. Also I can use 100% juice of 3900x, no problem. Maybe it really is problem with Intel ovens?

EDIT: I forgot that I have Intel Oven in my work laptop (how could I when CPU is the reason why it's hardcore overheating ). i7 11800H - no problems here either. I'm using Cubase every day on this laptop now.

[D-Fusion]

I am not sure what is up with Cubase 12 these days but it is horrible here (Cubase artist 12.52).

Vsts uses 2-3 times more cpu if the track that is playing is armed if you arm another track than the one that is playing the cpu goes down (VPS Avenger with a Sequencer preset shows that bug the better).

1. Instance of the latest version of Korg OPSiX show low cpu usage while playing until you release the notes and the cpu usage goes thru the roof until you remove that instance.

This happens on Both my AMD Ryzen and Intel setup so no difference there.

[Milkman]

I am not sure what is up with Cubase 12 these days but it is horrible here (Cubase artist 12.52).

Vsts uses 2-3 times more cpu if the track that is playing is armed if you arm another track than the one that is playing the cpu goes down (VPS Avenger with a Sequencer preset shows that bug the better).

1. Instance of the latest version of Korg OPSiX show low cpu usage while playing until you release the notes and the cpu usage goes thru the roof until you remove that instance.

This happens on Both my AMD Ryzen and Intel setup so no difference there.

Ive seen this happening on Mac/Intel, AMD, Win Intel. Steinberg (and 1000s of customers) have documented this for over 10 years, and steinberg has spend the last 10 years blaming customers, blaming other vendors, and now blaming the ENTIRE hardware and OS ecosystem for the problem they cant resolve, that other vendors have already resolved or worked around.

On all my systems that had the above symptoms, I did several things which reduced or stopped that high (internal ASIO overload) issue. If you compare your real CPU usage outside cubase to the internal ASIO meter, you see different things. (cubase hits 80-90% internal, 10-15% external "real" CPU).

I was able to reduce/remove the high load by:
1- totally disabling hyperthreading, all virtual cores.
2- totally disabling all CPU power management
3- disabling any dynamic clocking, such as speedstep / boost. I hard set my 6 physical cores to 4.00ghz, and the high load reduced down to 5-10% and stopped spiking.

On my newest system (12900KF, Z690 chipset, 32GB DDR5, focusrite 8i6 gen3 interface), I dont have to do ANY BIOS config to make all of it work perfectly. No high internal load, no high real CPU load, no pops or clicks, and everything works like a dream.

UNTIL cubase crashed and hosed my windows core audio and/or something I havent found. So I have 1 platform that does what you describe, and 1 platform that does not -- but poops itself when subase crashes. Fun times!

[Milkman]

Yikes! Looks like I did good by moving to AMD a few years ago.
But even on Intel I didn't had such problems. Now with Intel Outside, Cubase crashed a few times during plugins scanning but it didn't affected behaviour/ performance in any way. Also I can use 100% juice of 3900x, no problem. Maybe it really is problem with Intel ovens?

EDIT: I forgot that I have Intel Oven in my work laptop (how could I when CPU is the reason why it's hardcore overheating ). i7 11800H - no problems here either. I'm using Cubase every day on this laptop now.

These problems with cubase 9, 10, 11, 12 are very inconsistent, Ive found. My wife has an older i5 MSI laptop with 16GB RAM & an nvidia 1060 GPU in it. Some weird H series CPU or something. It has ZERO problems with cubase 12 and the native instruments libraries.

Our x299 intel i7800x 32GB DDR4 desktop, I struggled to work around the pops/clicks/internal overload.
Our Z690 intel 10900KF 32GB DDR5 desktop, works perfectly EXCEPT when cubase crashes. lol

Maybe if enough of us come to this thread, list our system specs, list our specific troubles with cubase, we can create our of "community QA - supported hardware" list for steinberg.

[AdvancedFollower]

They now claim, lol, that all the 10xxxK or F CPUs are no longer recommended for cubase because of the SAME issue that has plagued them for close to 20 years now. Each time this or a similar excuse is made, and they have once again said "this is a problem for not just us, and so we will wait for the industry to update itself for a fix."

There are different issues at play here. The latest issue is with "e-cores", which are slower more energy efficient cores meant to be used for low-priority processing to save on power/battery life. They were only introduced recently, not 20 years ago, and are currently only on Intel CPUs. The problem is that individual applications do not get to choose which cores to use, this is handled by the Windows task scheduler. This creates problems for realtime audio software since it's possible for time critical threads to temporarily end up on an e-core, depending on the workload and processor load at the time and the whims of the Windows task scheduler.

An older issue is the Windows limitation on the Multimedia Class Scheduler Service, which among other things means it can only use 32 threads (16 cores with SMT). That shouldn't have been an issue on a 7800X, though since it's only 12 threads.
The reason they recommend ASIO Guard is that it is designed to solve exactly these kinds of problems by switching as much processing as possible from ASIO Realtime path to its own processing path.

The issue with power management is similarly outside of the DAWs control. Too aggressive throttling of CPU cores when idle can create delays as the cores ramp up in response to load, and the constantly varying clock speed creates unpredictable and variable latency throughout the system. This has become less of an issue with modern processors which handle power switching much faster, but even relatively recent ones like my Ryzen 3800X require some tweaks to reduce the latency in clock selection from 15ms to 1ms (using a power plan provided by AMD). Or you can simply disable power saving, although this will obviously cause the system to draw more power and produce more heat.

Personally I haven't had any issues with Cubase. Performance is excellent on my AMD Ryzen 3800X. Of course I haven't tried powering my computer off in the middle of a session as there is definitely a risk of corruption, not only of Cubase-related files but also of OS files or project data. With an SSD, it's even possible to physically damage some flash memory cells that way. If you have unreliable power delivery where you live, a UPS might be a good investment.

It's also worth taking a step back and calmly look at the situation. It's clear there are some system-specific issues relating to hardware, configuration or drivers. Cubase is used by many thousands of hobbyists as well as professional studios. If the program were this unstable and performed this poorly for *everyone*, nobody would use the software.

[D-Fusion]

---------

[Sahul]

Vsts uses 2-3 times more cpu if the track that is playing is armed if you arm another track than the one that is playing the cpu goes down (VPS Avenger with a Sequencer preset shows that bug the better).

This is not a bug but basically the way ASIO Guard is implemented. If you arm an instrument or MIDI track, Cubase understands that you want to play that instrument in real-time, so it switches to the lowest latency your ASIO Guard configuration allows, hence the high CPU use. However, if the track armed is an audio track, ASIO Guard will switch to high latency mode, so performance will be much better.

[D-Fusion]

Vsts uses 2-3 times more cpu if the track that is playing is armed if you arm another track than the one that is playing the cpu goes down (VPS Avenger with a Sequencer preset shows that bug the better).

This is not a bug but basically the way ASIO Guard is implemented. If you arm an instrument or MIDI track, Cubase understands that you want to play that instrument in real-time, so it switches to the lowest latency your ASIO Guard configuration allows, hence the high CPU use. However, if the track armed is an audio track, ASIO Guard will switch to high latency mode, so performance will be much better.

Thanks for your explanation
I discovered that i don't should pay to much attention to the Performance meter

Did some testing and even if those other daws show lower cpu usage in their performance meter They all maxed out at the same numbers of instances as Cubase did so Cubase is showing it correctly.

When it says it is maxed out it is maxed out and the others shows 50-60% usage when they are maxed out.

[Synthman2000]

Milkman may I ask what audio interface you are using, did it remain the same for all the machines ?

[Milkman]

They now claim, lol, that all the 10xxxK or F CPUs are no longer recommended for cubase because of the SAME issue that has plagued them for close to 20 years now. Each time this or a similar excuse is made, and they have once again said "this is a problem for not just us, and so we will wait for the industry to update itself for a fix."

There are different issues at play here. The latest issue is with "e-cores", which are slower more energy efficient cores meant to be used for low-priority processing to save on power/battery life. They were only introduced recently, not 20 years ago, and are currently only on Intel CPUs. The problem is that individual applications do not get to choose which cores to use, this is handled by the Windows task scheduler. This creates problems for realtime audio software since it's possible for time critical threads to temporarily end up on an e-core, depending on the workload and processor load at the time and the whims of the Windows task scheduler.

An older issue is the Windows limitation on the Multimedia Class Scheduler Service, which among other things means it can only use 32 threads (16 cores with SMT). That shouldn't have been an issue on a 7800X, though since it's only 12 threads.
The reason they recommend ASIO Guard is that it is designed to solve exactly these kinds of problems by switching as much processing as possible from ASIO Realtime path to its own processing path.

The issue with power management is similarly outside of the DAWs control. Too aggressive throttling of CPU cores when idle can create delays as the cores ramp up in response to load, and the constantly varying clock speed creates unpredictable and variable latency throughout the system. This has become less of an issue with modern processors which handle power switching much faster, but even relatively recent ones like my Ryzen 3800X require some tweaks to reduce the latency in clock selection from 15ms to 1ms (using a power plan provided by AMD). Or you can simply disable power saving, although this will obviously cause the system to draw more power and produce more heat.

Personally I haven't had any issues with Cubase. Performance is excellent on my AMD Ryzen 3800X. Of course I haven't tried powering my computer off in the middle of a session as there is definitely a risk of corruption, not only of Cubase-related files but also of OS files or project data. With an SSD, it's even possible to physically damage some flash memory cells that way. If you have unreliable power delivery where you live, a UPS might be a good investment.

It's also worth taking a step back and calmly look at the situation. It's clear there are some system-specific issues relating to hardware, configuration or drivers. Cubase is used by many thousands of hobbyists as well as professional studios. If the program were this unstable and performed this poorly for *everyone*, nobody would use the software.

Thanks for taking the time to write that. YOu may not be a subscriber to the steinberg forums, but if you are you can see many people - going back 5+ years - complaining of these issues and a few others. Im not even talking about the crashing, lol.

I do, however, understand quite well the ecosystem in which steinberg is attempting to exist, and I do understand where steinberg is and is not investing their time and money. Ive been involved in all this for about 20 years now, and my job as a net/sysadmin with lots of experience supporting live artists + live streaming + large S&E venues, gives me some insight. I was hoping others who've been down this road (with steinberg) could share their experience, or their platform, to compare against.

This issue has existed in one form or another since 2002, when the first Core2Duo was released. When I was using SX 2, I immediately followed steinberg's recommendation and turned off virtual cores, and this allowed sx 2 to run well and with minimal dropouts or overloads. Nobody was under the false impression that steinberg COULD make this work back then, and we agreed to just turn it off. There was no "ASIO guard".

Then I took a break from cubase for a few years, and came back to purchase a 10 pro license. C10 and 10.5 pro had the same issue seen in sx 2, 3. So I went on a long (3 years) testing spree, configuring laptops, repurposed workstations, 2 different brand new desktops, etc, in an attempt to find the magic hardware platform that can work around the multimedia multi-threading issue and/or dynamic clock speed and/or dynamic power management "issue" that other DAW vendors(including those who used to work for steinberg, but left for bitwig) have little trouble with. (Ive tested all of this in Live, including my entire plugin and content library, and it never had any of these issues.)

I was told "ASIO Guard" resolves this hyperthreading issue for the "vast majority of users". Turn it on! Nope. Guard on/off on any setting still resulted in pops/clicks/overloads. On those platforms, the only way to work around this was to disable all virtual cores (lol), CPU power management, and CPU dynamic clocking. Steinberg would never publish a list of those changes, or a list of hardware specifications that 1) didnt have the issue 2) could be worked around. I asked over and over again.

I reached out to steinberg directly and on their forums, thinking this issue would be high on their priority list to either adapt cubase to, or configure the windows environment in such a way to minimize this problem using their robust QA and engineering resources. (like other vendors have)

However instead of admitting this issue - an issue which 1000s of people on the steinberg forums have reported over the years - they had most users who reported the issue go on a wild goose chase, such as having them disable NICs, making claims that nvidia GPUs are the problem, making claims that until you have replaced all core system components you "havent done adequate troubleshooting", making claims that "your task manager isnt telling the truth", etc. I literally documented and published links to 100 threads on the steinberg forums because of this -- to show others proof that MANY people are experiencing this across intel, AMD, Win, and MacOS.

So after ALL this time, and in the face of what steinberg's own documents say today (cant use most new Intel CPUs), Ive built an i9 10900KF system with DDR5 and a 3090ti GPU that is imo the perfect environment. Real CPU usage and internal ASIO usage are amazingly low, barely every topping 10% on 1 or 2 cores even when I test out CPU hogs like NI's Pharlight, Straylight, etc. Zero pops/clicks, and ALL CPU power management, dynamic clocking, etc, features are enabled. ASIO Guard is always off on this machine because it increases average CPU use and Im never even close to overloads.

The ONLY thing that can cause a problem in this environment, documented twice now, is if cubase crashes during runtime. All of this seems to be something QA and dev resources could *at least* shine some light on, but I dont think steinberg is 100% honest about what they are doing here.