Strange ASIO Behavior when Cubase in Background

Cubase
1

After the most recent update, I am getting some odd activity in Cubase, which might be linked with a previous issue I had. So first, some context: While using 13 Pro, I noticed that when Cubase is running in the background, and I place another application over it, the performance dropped fairly drastically. The meter would peak while playing very basic songs with virtually no processing. It would go away completely by simply removing the application covering Cubase, simple enough. Somewhere towards the later version of 13 Pro, this seemed to go away completely, or at least I did not notice it happening anymore.

I should mention that this is not a computer performance issue; I have a 13th Gen i9, 64 gigs of DDR5, dual vNANDs, RTX, the works, so I know this has nothing to do with a performance issue because everything (other than this one issue) works perfectly.

14 Pro did not seem to have this problem, which I was thankful for. However, now I have encountered a new problem with the 14.0.10 update. It seems to me while I am switching over to other applications (same deal, on top of Cubase) I get these occasional bursts of sound in the background, like the track suddenly started and stopped in a split second. It is quite loud and very annoying. I checked the performance meter, and it has not spiked. I was familiar with the popping issue of old where the meter spikes while inactive; this is not that. So, I doubt this has anything to do with power management or ASIO Guard.

I have tried all the usual things; I have been using Cubase for two decades. So, I am familiar with the normal routine, but this one has me puzzled. It is not a performance issue, and as far as I can tell, it is not a license issue either. It happens on two different projects that do not share any VSTs. One is primarily a MIDI project, and the other is 100% audio. Yet, something clearly hangs up Cubase for a split second… while simultaneously causing some kind of reset, because the sound starts/stops without the project playing, which is what I find odd.

Fortunately, it is not a common occurrence, but I wrote this because I have experienced it twice in 16 hours, and now I am curious as to how to prevent it from happening. Since there is no crash, there is nothing to report. So, I am at a loss for data.

Now, I did install a few VSTs lately from Black Friday, but I do not have any of them running. One is by SINE, one by InMusic, and one by Waves, but I doubt that is the problem, since, as I said, they are not running on any of these projects. The only major update I did was to 14.0.10, and I do not recall this happening before that.

Anyways, I am going to simply avoid running applications on top of Cubase to see if this prevents it from happening. If not, then maybe it is completely unrelated to the previous issue. We shall see…

2

Are you running Nvidia studio drivers? If not, that’s one of the first things I’d try to combat mystery audio dropouts.

2 Likes
3

Thanks. Yes, I am using the newest studio drivers and all my other drivers are updated. I have heard of some strange phenomena with chipset drivers. So, I have those all updated as well… but I see your thinking. The fact that it only happens when things are overlapped does point to perhaps a graphical issue. Yet, it does not occur in any other applications. It seems unique to Cubase. I have avoided placing anything over it for the time being, and I have not heard the sound since posting this.

Also, it is not so much a dropout as much as either a stutter while playing or a loud boom now and then when it is not playing. I do have a “theory” though that it is a cascade of some kind because, for example, if I place Discord over Cubase and run a song, the playback gets progressively worse as the longer I leave it on top, whereas it vanishes when the app is removed from covering Cubase. So, something very specific and strange going on here.

4

What a strange issue indeed.

I guess, another thing to investigate might be ASIO and/or Windows audio? And potentially update and/or re-install audio drivers?

Because there’s an ASIO setting to release the audio when Cubase is not in the foreground. So there’s some code path that gets executed differently, depending on that setting being on or off.

Here is how I’m running my Cubase Audio:

Cubase13_YXszhQjdr2
Cubase13_YXszhQjdr2722Ă—801 35.1 KB

Is it also happening if you have Discord as application the foreground, but not overlapping with the Cubase window(s)?

I’m also running Discord (and Firefox) quite a lot and don’t seem to have encountered the same issue.

However, I was just able to reproduce something similar with lots of audio dropouts, while running LatencyMon while playing a simple long audio track in Cubase. It may be a different issue (also because it didn’t seem to matter if LatencyMon was in the foreground or background), but it does prove that another application can trigger audio weirdness in Cubase - at least if it digs deep enough into the OS.

1 Like
5

These are solid points and good theories. I usually have the Release Driver off, but I might see if there are any differences with it on, just to be sure. Windows also reactivated some USB items that I always keep disabled, both my onboard sound card (which I keep off) and this silly “Smart Sound Technology,” which I think can create problems in the DPC/ISR. I just disabled them again. So, I shall see if that perhaps solves the “boom.” I am not sure how they got turned back on to be honest.

I have not experienced the boom again yet, but I like the notion that the foreground/background coding could be a potential culprit for the sudden call/interrupt issue. I am going to do a little more experimenting with this, but I need to get back to work, of course. If the problem disappears, as they do sometimes, I might simply put it a folder and file it for now.

Alternatively, I used to run all PC audio on my sound card and route it into the interface and simply monitor it. This keeps the interface dedicated solely to Cubase. I just hated doing that because the on-board sound card has annoying motherboard bleed from the ethernet port. Who designs this stuff? Anyways, thanks for investigating this with me.

1 Like
6

Update: So, I turned off the Smart Sound Technology, and it appears that the overlay problem has actually stopped. I have three applications over Cubase right now with the song playing and Discord conversation going on, and it appears to be fine. Perhaps the SST was causing a problem in the DPC/ISR latency? I could see that being an issue with USB audio and data loss. It is definitely not designed for interfaces.

1 Like
7

Thanks for your updates. That’s interesting observations, and may end up becoming very useful for others bumping into this thread.

I’ve been running an RME audio interface for a few years now, which handles both, ASIO and Windows Audio natively in parallel. And before that I ran Steinberg interfaces, which also handled both, ASIO and Windows audio.

That allowed me to entirely disable all motherboard and HDMI audio, so Windows doesn’t even see it.

Maybe that was one of the things that’s helped me to avoid the kind of issues you’ve described?

But yes, Windows updates sometimes reverse my customizations as well. Or install a bad driver over a good one. So I’ve used the Group Policy Editor to delay some Windows updates for a year. But that’s a bit more adventurous.

Between gaming GPU drivers and motherboard audio, there could be a lot of low level kernel level interference being generated. And ASIO reaches pretty low into the OS, so clashes are probably not all that surprising. But without that low level stuff, we couldn’t get high performance audio and graphics - so we’re on somewhat thin ice all around.

1 Like
8

Yes, I might actually create a policy to avoid that because I always go through and disable anything that is known to and/or could possibly cause an issue. This computer is only used for audio. Occasionally, a co-worker or assistant might also use it. So, there is always the chance they will actually change something accidentally. Better to make the customizations more accurate. Thanks for that idea.

I also used Steinberg interfaces, mainly URs, but when I finally had enough saved to switch to my dream interface, the AXR, they were already impossible to find in the US. I am still kind of angry about that because I wanted one for so long. I switched to a Focusrite Clarett for some time, but I hated it. I went through a few more and ended up with the Arturia Audiofuse, because it fits my multi-synth studio setup. I use all 16 line ins, and an additional 8 through ADAT. This is what I presently use with Cubase.

Anyways, no problems anymore. I believe the culprit was likely this Intel® Smart Sound Technology which they describe as “an integrated audio DSP (Digital Signal Processor) built to handle audio, voice, and speech interactions.” I would assume that it does not apply itself to ASIO but perhaps having it running messes with the Windows audio which Cubase releases? Just a theory of course, but maybe somewhere down the line, between ASIO and the SST DSP, those calls/requests start piling up and perhaps cascade? Sometimes, I feel like if we could just move beyond isochronous audio signals, this stuff will all be a moot point.

Now, onto getting that policy created. Thanks again.

1 Like