Okay, this is really weird – I initially read about it in a Facebook group, then experimented with it myself in my latest project. The basic scenario is, you have a project that has audio dropping out, and you can’t just adjust buffers or other similar things to cure that, BUT, if you add a HALion (Sonic 7 in my case) instrument track to the project, all of a sudden the project plays smoothly. And this is repeatable, not just a temporary thing – e.g. disable the Halion track, and the dropouts come back, reenable it, and they go away again, repeat ad nauseum with the same result.
I did a little digging, and the key seems to be that adding that HALion track somehow shifts the balance of CPU usage away from the first CPU to balance it more with the rest of the CPUs. Here is a Task Manager performance tab shot of CPU usage with the HALion instrument track (BTW, no instruments are loaded in HALion, nor is there any MIDI data on the track) disabled:
Note the consistently high usage of the first CPU with relatively consistently low usage of the other 11 CPUs, with only a few minor spikes on those other CPUs.
Here is the same shot, running the same project after adding the HALion Sonic 7 track to the project:
As you can see, the first CPU still has higher usage than the others, but it is lower than it had been without the HALion track enabled. Meanwhile, a number of the other CPUs get higher spikes, assumedly due to taking up some of the slack from what was offloaded from the first CPU.
On the one hand, this is cool because it may provide a workaround to avoid dropouts in some cases (it seems to be doing that on my current project). On the other hand, it is a bit befuddling. Why should ADDING an instrument track, even though it isn’t actually doing anything, make the CPU scheduling work better? Wouldn’t it be better if whatever is going on here would work with Cubase in general?
This gave me the idea to see if I could change the Cubase13.exe process’s affinity to tell it to avoid the first CPU. That had been something I’d seen suggested for other DAWs in the past, and I remember it seemed to (sometimes) help with SONAR (I actually found the idea in a Pro Tools forum when searching on the general performance issue). However, it either did not make a difference here (i.e. with the HALion track disabled, there were still heavy dropouts), or Windows was not letting me change Cubase 13’s affinity to not use the first CPU (or maybe Cubase somehow reset it – in particular, Task Manager seemed to let me make the affinity change, but when I went back to unset it after observing the results, the CPU was still enabled for Cubase).
I’m hoping this info will provide a clue to help figure out some performance/dropout issues. (I suspect the guy who reported this in the Cubase Pro Facebook group has a much better configured system than I do.)
Thank you for confirming this with no prompting Rick .
It’s a bizarre one , on some hands really great by having HALion active gives you a vast amount more track count BUT on the other hand as i mentioned in the group if you don’t know this and backup project for the future and DELETE the HALion track you are in a world of pain , it’s the same with GA as well my friend , the funny thing is ALL my 3rd party synths do not do this NO rant , just facts Cubase 13 Audio engine Spikes compared to Cubase 12 - Cubase - Steinberg Forums
Interesting. After posting this, I got wondering about that possibility. I don’t use GA, and haven’t used HALion all that much to date, but I use Kontakt a lot, and also some others like Superior Drummer 3, MONDO BASS, UVI Workstation (for Acoustic Samples guitars), MusicLab, etc.
I just tried now with Kontakt 7 (latest released version), and it worked the same as HALion in this regard, but put out a very different – way more balanced – performance graph in Task Manager:
And no dropouts, either – I even tried disabling it (massive dropouts) – then reenabling it, and again no dropouts to be sure. This is playing the same project as earlier from roughly the same point, but I did have a break of a few hours in between.
Ditto for UVI workstation (again no actual samples loaded), and a similar screenshot to Kontakt 7. And SampleTank 4, and East-West PLAY, Spitfire BBC Symphony Orchestra, and AnalogLab V!
Interestingly, after trying all those, then going back to HALion Sonic 7, its CPU graph is similar to the one I pasted above for Kontakt 7 (as are the rest) – i.e. way more balance overall, rather than showing a significantly higher load on the first CPU despite being lower than the case with no sampler/synth at all. But, if I disable the synth again, then we’re back to the very high load on the first CPU, just like the original screenshot I’d posted. And, of course, the dropouts in playback.
Im not at the Pc at this precise point BUT i think by default H7 multicore (in the Options tab) is set to OFF , you can adjust the amount of cores ( well ,you can in H7 ,not sure about Sonic ) , does this make any difference with the balanced Sonic useage ?
Adding instruments works for me as well. Big thanks.
I’ve had a long history of this problem on my Dell system. This confirms my theory that, at least on certain systems, Cubase has issues with core-sharing in low-load, low latency projects. I compared with another DAW which is much more stable for me when starting an audio recording project, and like your screenshots, the other DAW had very even core distrib. in comparison to Cubase. Adding Halion or any instrument is a method of increasing core ussage and clearly after a certain level of core-strain Cubase begins to share-out the processing better. Makes total sense, Thanks for the posting.
I see @Highly-Controversial has already responded to this part, but I hadn’t even thought of that when looking at it last night. I’d just added the track, and tried switching out different virtual instruments on that same track while doing my testing (enabling/disabling and checking Task Manager during playback of a significant section of my song). But, because it was an instrument track, and those automatically have monitoring and record enabled when I select them, it would have had both active.
In fact, as I was getting ready to stop for the night, I changed the focus to another track, and the audio dropouts came back. And, after that, I could not get that same project playing back cleanly even after going back to the HALion instrument track (and I did try tweaking both the record enable and monitoring enable to see if either or both in combination would make a difference). So now I’m a bit stumped as to whether this will really help in practice. But I’ll be working on the mix of the project in question today, so I may get some sense. (It may be hard to tell, though, as I’ll be bringing back a bunch of tracks that are now either frozen or disabled due to having used some submixes/stems for tracking in the last few days, thus causing a moving target on the performance needs of the project at any given time.)
My system is one I built myself back in 2014, so no spring chicken at this point (though it does at least have SSDs for both the system disk and audio disk at this point). But, even in its early days, it did not seem to be performing as well as I expected it should in various areas that I believe relate to latency and balancing of resources. I ended up doing a lot of research/reading/testing over the years to see if I could find some magic bullet (or, more likely, magic combination of bullets) to address the issues, with the main symptoms at various times (and not always happening, even around the same time) being artifacts (e.g. clicks and crackling) in audio recordings or dropouts during playback. At one point I was also working closely with Cakewalk’s chief engineer (my main DAW until Cubase 10.5 was SONAR) to run various tests with tweaks to parameters they have available that relate to this area. Unfortunately, my system cannot be a dedicated DAW (for a combination of financial, workflow, and space reasons), so that may make my considerations more complex than some would have. But the bottom line is, while my system usually performs well enough for my needs, as long as I’m willing to work around my system’s limitations, I am able to get by, and I can’t afford any meaningful upgrades at this stage.
You mentioned issues at low latency, but my test last night was at high latency – 2048 samples at 96 kHz, which is the highest my MOTU 828x interface will go and what I usually use when mixing. The project also wasn’t super complex at that stage because I’d submixed all the instrument tracks while tracking, comping, editing, and tuning vocals. Most of the underlying tracks were disabled, with any plugins on group buses also disabled. What was left was one audio track of the instrumental submix, 4 frozen mono background vocal tracks going to a BGV submix bus with VocalChain on it, and a lead vocal track (mono but converted to stereo) with maybe 4 plugins (at least Antares Mic Modeler and VocalChain, but I think maybe one or two others) on it. Those 3 sources fed a mix bus with two plugins (I think a tape simulation and then Waves AR TG Mastering), which in turn went to the Stereo Out with Ozone 10 and PSP X-Dither on it. Of course, some of those plugins were reasonably heavy duty – Ozone, in particular.
Separately, I’ve also seen some cracking/clicking issues in recording vocals at low latency. I usually start with 256-sample buffers at 96 kHz, but, if it is crackling there, sometimes the solution is unintuitively to lower the latency, to 192-sample buffers. In my most recent session, though, I had to raise the latency to the next higher buffer size (384).
From doing a bit of reading this morning, I see that the ASIO-Guard thread is separate from Cubase’s ASIO real time path, so maybe what happens here is that “luck” (i.e. with Windows CPU scheduling elves) was putting HALion, which would have been on the real-time side of things, but having no significant performance impact, on the first CPU, thus forcing ASIO-Guard processing (assumedly the rest of my mix) to go elsewhere, at least at the moment when things were working (see my note above about later results).
This brings me back to my thoughts on the affinity setting, though. What I (vaguely) recall from the ProTools forum discussion on that was that they were suggesting not letting the DAW use the first processor, with the logic that it would be the main thing used by various system-related processes, and, as long as you had enough other threads, there’d be better odds of getting as much services as you could if you weren’t competing for that first processor. IF that actually makes sense (i.e. in terms of the way Windows works in CPU scheduling), it does make me wonder if there might be something that could be done in Cubase settings (perhaps as an optional preference) to have it avoid scheduling on the first processor (or maybe even more than one specific processor) in the case empirical results on a given system find this to make a difference.
One more piece of information that I’m pretty sure is related to this phenomenon: When the load gets very heavy, but having the focus on a HALion Sonic track that is essentially doing nothing (other than creating an ASIO real-time thread that somehow helps with balancing the load on CPUs, likely relating to CPU affinity), sometimes temporarily selecting another track (i.e. other than the HALion track) can create a HUGE noise spike, which is not only painful to the ears, but actually registeres +100 dBFS on the meter:
The first time this happened to me I’m pretty sure playback was running, and I’d just selected a frozen instrument track (which also had volume automation on it) in the MixConsole window, because I wanted to add a VCA to that track. However, some other times when it happened, again selecting tracks other than the HALion track, playback wasn’t even running, and Read automation for a quick fade up at the start of the song would have the stereo out fader at negative infinity (as can be seen in the above screenshot).
I’ve had a few times where the HALion trick stopped working temporarily, but this was mostly when my plugin load was already quite heavy (for my system anyway), and sometimes disabling a single plugin would have it working again and even reenabling that same plugin later would still have it working.
There is, of course, going to be some point on every system where a threshold is reached, and that may relate to a combination of the underlying ingredients such as CPU/motherboard/etc., audio card drivers, sample rate, and more.
I hadn’t heard of Process Lasso before but just looked it up, and I see it claims to be able to tweak CPU affinities. Normally that can be done from Task Manager’s Details screen, but I’d tried that with Cubase 13 the other night, and it wasn’t seeming to let my tweaks stick, unlike when I’d tried it in the more distant past (I think with SONAR as I think it was before I started using Cubase). This made me wonder if something in Cubase is overriding any affinity settings made outside of it.
I’m not sure the AudioGridder situation is apples-to-apples here. It is probably a lightweight plugin in Cubase that does the heavy lifting elsewhere, thus shifting the load naturally around to other CPUs (since it is a separate process from Cubase, unlike the VSTs running within Cubase). But perhaps that notion (i.e. shifting VST load to other processes) is something that could ultimately work within Cubase, too?
I do know, from the other thread that is related to this topic, that Steinberg at least seems to be looking into the potential that CPU affinity is coming into play here, and that it could be the changes that they made to improve things on newer CPUs could be having negative effects on older CPUs (which mine definitely is at this point).
This is just crazy. I’ve been struggling getting the same performance as with Cubase 12 all day now and the only thing that actually worked was this Halion 7 workaround. Everything else I tried resulted in audio dropouts in my projects that used to run well on Cubase 12.
I tried process Lasso to change CPU affinities, I disabled Hyper-Threading, I deleted all Steinberg related things from my PC and rinstalled a fresh cubase 13 install, but nothing has worked so far.
REALLY disappointed that I spent money on upgrading to 13.
I tried killing hyperthreading, and it improved the situation. No more pops and clicks. This is the first time killing hyperthreading has worked for me, though it’s been mentioned many times in other threads. The situation is very much a moving target. At least I can record audio now though.
See this entry from @Ed_Doll of Steinberg in another thread:
The good news is Steinberg is actively investigating this issue. Hopefully that means it will be addressed in the next maintenance release.
In the meantime, I have at least found that the workaround does the trick, at least to the degree my system can hold up in general (including in Cubase 12 and earlier – my system is one I built in 2014, so not a modern CPU at this point).
Might be way off, but once upon a time I was suffering from issues that looked kind of like this on the surface.
Drove me nuts, but one day I discovered a pattern. Anything that ‘spiked’ was streaming audio from a specific make/model of SSD drive. Stuff from other drives…never an issue.
It was weird because the system passed latency mon checks with flying colors. The drives in question bench mark well. Nothing made sense, but the drive, or drivers for it was doing some kind of regular interrupt that latency mon didn’t show should be much of a problem, but lawdy does it wreak Havok on audio streaming!
I watched someone’s video in one of these related threads and tried the same plugin/library (Opus with Fantasy Strings)? If I host the library on Samsung SSD media, no spikes. With just the one instance of Opus, I can drop ASIO buffers to almost nothing.
Put that same library on the PNY SSD media, and I get regular spikes like crazy…even glitches with massive buffer sizes up to 4mb!
For what it’s worth, the issue popped up years ago, with super lean sample libraries by today’s standards (Garritan stuff…light enough to pile up tracks on old single core Celerons). Wasn’t just a Cubase thing in my case. Other DAWs suffered to varying degrees, but Cubase was indeed the ‘most sensitive’.
While this may be interesting to others on the general streaming performance front, it is not a factor in the HALion (or other virtual instrument) track addition workaround mentioned in the subject of this post. It truly does result from CPU balancing issues, where adding the extra real-time ASIO stream seems to shift the balance away from the first CPU.
However, it is a good point with respect to sample library, and other audio, streaming in general as an underperforming disk can result in serious dropout problems. I found that out initially when I had a failing hard disk that was my audio disk some years back, after noticing that freezing tracks actually started making dropouts worse instead of better, because they were now not just a factor of my limited CPU, but having to stream off a failing hard disk whose performance was extremely compromised. (FWIW, that drive, and more recently my system drive, have now been replaced by Samsung EVO SSDs. I still have a hard disk for sample libraries at this stage, though that has never become a bottleneck to date, but I’m not doing huge numbers of sampled tracks like orchestral composers would be doing.)
I think I replied to the wrong thread, and I can’t find it now. Seems like I had several tabs open and got all mixed up. The one I thought I was addressing…some guy had posted a video of Cubase 13 with nothing but a single instance of Opus and he was getting terrible spikes.
Still, back when I was tearing my hair out I did discover that similar tricks (having a certain combo of things running and routed a certian way) ‘seemed’ to help some, but never really truly smoothed it out.
It was/is strange indeed. I’m talking a single instance of sforzando playing a simple single layer oboe or something. Play one key, a sample less than 3 seconds long. and SPIKE.
Since then, one of the first things I check if I see spikes like that, is moving anything that does a lot of data streaming from storage to a different drive.
Theory, some drives don’t like trickle streams. They want it to be full throttle with massive sized chunks, or not at all. Their drivers seem to stop a core and sit there until the ‘chunk’ is full, spill it, then repeat. The drives kick butt in ‘bench marks’ for loading/saving big files but are terrible for a/v streaming
Yeah, I saw something along the lines of your theory when reading SSD drive reviews when I had to replace my system drive recently. I think PNY was one I’d read that about, and Samsung got good marks (at least in the EVO series I’m using), so I stuck with them.
Yes, I have at least 3 generations of Samsung. Some NVMe, some SATA3. All ‘plus’ or ‘pro’ models. I’ve been having good luck with Samsung when it comes to flash memory tech.
The PNY drives I picked up years ago were SATA3, and got a small batch for pretty cheap. Gave them a try on both intel and amd systems of different generations and they always gum up the works. Oh well, they’re still working fine for anything that doesn’t need to ‘constantly stream data’.
Let’s hope Steinberg take this seriously
