Audio dropouts, clicks and pops, but CPU at 30%?

Hi folks!
I’ll apologize ahead of time for the long-winded email.

I’m not sure where else to turn to since this is such a specialized issue. I’ll give the specs and then I’ll continue:

I have 2 Windows machines as follows:

  1. a Sweetwater Creation Station CS450 (desktop computer) running Win10 completely updated with 32gb ram, i7-8700 @3.2gHz
  2. a Dell XPS Laptop running Win11 completely updated with 32gb ram, i9-9800HK 2.4gHz, completely debloated, and optimized for audio as best as I could research. I’ve also noticed that it’s running at about 30% CPU, and that its clocked at 3.1-3.2ghz when running said Cubase project. No throttling SEEMS to be happening, according to the CPU monitor.

My problem is as follows:
Cubase 12.0.52.
Same project running on either machine, the CS450 runs smoothly, with no dropouts at all.
On the XPS, the audio drops outs with audible clicks and pops every 2-10 seconds, and more annoyingly sometimes like every second.

I know the first thing folks will say, is what plugs are you running? WELL!

  • I’ve narrowed the problem down to which plugin is killing the XPS, and it’s Podfarm 2.5. I have about 10 instances of this plug running simultaneously in this project. Whenever I DISABLE these plugs, the XPS runs perfectly smooth. So, bingo, there’s my problem. (And btw, I have gobs of other plugs and VSTi’s running, but none of them seem to affect the XPS or the CS450).
  • Probaby the next thing you might say, well then go back to Win10 on that XPS! I’ve upgraded to Win11 actually because the same thing was happening when it had Win10 running, I upgraded in the hopes to mitigate that, especially after debloating.

My question is, why the hell would my XPS be dropping out, and the desktop not even flinch?

I’ve done a hell of a lot of research on this, and I’m coming up with nothing at every turn, or inconclusive at best. Originally I believed it would be a CPU throttling feature to prevent overheating. I’ve disabled all of this in Windows, but as far the BIOS, I’m not sure as it’s more or less greek to me. And with the XPS there is a LOAD of settings in the BIOS, more than I’ve seen in previous BIOS settings on other computers. One other interesting thing is the XPS laptop never goes beyond 32-33%, but the meters in Cubase show a CPU overload however, and the ASIO-Guard goes all the way up and all the way down again, repeatedly. ??? So yeah, mixed messages there.

I’ve been running LatencyMon as well, which also is greek to me. :slight_smile: haha. BUT, it definitely is stating that my XPS is having trouble keeping up.

I need to get this solved, so I’m all ears as to suggestions. I don’t see a logical reason the 2020 XPS shouldn’t be keeping up with the older Desktop from 2018. Yes, we’re looking at 3.2ghz as opposed to 2.4ghz on the XPS, but I find it hard to believe this would cause so drastic a difference.

If you’ve run LatencyMon then I’d start there if I were you. Just read up on what the results mean and take it from there. I haven’t used it but my understanding is that once you’re above a certain range you’re likely to get dropouts, and that the software will show you what is causing those latencies (i.e. GPU for example).

There are several reasons why a laptop might struggle vs a desktop of similar speed and capacity. A laptop is generally configured to preserve battery so power saving options are usually on by default.
Have a look at the BIOS to see if you can configure C-states, Speed-step, etc. These are parameters which, when enabled, allow control of CPU speed to minimize power draw and often cause interruptions which are reflected in Latencymon (and your audio path). They should be disabled if possible.
The other thing is to make sure that you have the highest performance power profile active on Windows (Ultimate Performance if it’s available to you) and even then go through the parameters to ensure that power management of USB and network ports is turned off.
Laptop vendors also have a bad habit of loading up their devices with various ‘utilities’ which can cause unnecessary interrupts, so turn these off or uninstall them if you can (except for the ones you actually need).
Lastly (and most disappointingly) there are laptops out there with minimal configuration options where latency issues can never be fully resolved. Hopefully your XPS is not one of those.

As far as CPU is concerned, you may have an average of 30% CPU consumption but you may have one core running at or near 100%. If your project has an audio path serialized on one core (e.g. track>plugin inserts>group>plugin inserts>master bus>plugin inserts) , if that core is overloaded you’ll get dropouts, even if the other cores are idle or lightly loaded.

Regarding Windows 10/11, we’ve run machines here on both Windows 10 and 11 and seen no appreciable difference in performance. This only becomes meaningful on 12th gen and later Intel processors with P and E cores, where Windows 11 is optimized for such architectures. This is not relevant to the processors you’re working with.

This is all super helpful information, thank you so much. I’m actually fearing the worst and that I can’t influence this thing to do what I want it to.

I’ll bet you any money this is exactly what’s happening. I was observing Latency Mon… TWO of the cores were being used, the other 14 weren’t. At least, comparatively. Is that the way it’s supposed to be?
Not to mention - yes, I certainly have all 10 tracks running Podfarm grouped and from there, obviously going to the master bus which definitely has a few plugs, but nothing crazy. But, what else am I supposed to do? This is how you’re supposed to mix, by utilizing groups and folders, and whatever else to stay organized. Are you suggestions I can’t do it that way?

Anyways, concerning the BIOS - I’ve gone thru it with a fine tooth comb and set everything to what it should be for performance. Speed Step off, etc. Also, the highest performance profile that was available to me was “Balanced Performance” I believe it was called. So, I had to custom make one, and I went through some tutorials to enable the best performance I could.

Totally stinks if I can’t use this thing, I love the XPS as a whole, it’s a marvelous machine in it’s design and ergonomics, not to mention it’s 4k display is out of this world. Beats the hell out of any Mac machine I’ve seen, and I love the displays on those too. I’d be so bummed to see that have to go.

But, if I can’t run what I need, that’s what I need to do.

Question for you… let’s say I CAN’T disable all the stuff I need to get this running the way I need… is there a way I can buy my way out of this with either more memory (currently running 32gb), or a different processor, in which case I’d have to look at a newer XPS machine… ?

  1. XPS is famous for audio dropouts due to the RTX graphics card. Try updating the drivers or try replacing it with a AMD version if possible.
  2. Using less core could be also an issue.
  3. This video might be useful.
    CPU Performance vs. Real-Time Performance in Digital Audio Workstations (DAW) - YouTube


I’ve had the same problem for ages with several versions of Nuendo on a Mac. The audio engine treats groups and fx tracks as realtime, bypassing ASIO guard and eating cpu very fast. It’s a workflow killer for me too. The funny thing is that if you put those plugins on every audio or instrument track they work just fine…

No, I’m not suggesting that because, as you say, this is what we do. But it’s important to keep these things in mind when you’re tracking or mixing. Every single thing you do in a DAW comes with a trade-off in resources.
I’m not familiar with Pod Farm but it appears to be an amp-sim, and these sims tend to be resource hogs. Maybe print the sim tracks once you have the sounds you want and turn the sim plugins off. That will give you some relief.
You haven’t mentioned anything about buffer sizes but, when you’re mixing you can increase the buffer sizes which will alleviate the stress (somewhat) on your CPU.
Back to your laptop again, @suseka above makes a good point about the graphics card / drivers, but it’s not just graphics. Poorly written drivers (for network cards, USB ports, even the SM Bus) can lengthen interrupts and cause performance degradation. And make sure you have radios turned off (like bluetooth). These also can have a negative impact.

More memory really won’t help you here. A faster processor might help you if your problems are specific to workload / CPU demand, but likely won’t if the problems are due to latency issues within the system.

Is the podfarm software dongled to their hardware?
In that case their asio driver may be a problem.

Hi guys,

So I’ve continued to wrestle with this issue on my XPS and I have a new development. Or rather a new finding that is very curious and makes this whole thing even more baffling.

So, just for the hell of it, I decided to load up my most power hungry, resource hungry project that I’m working on right now. Almost a hundred tracks, about 20+ tracks running Podfarm, same scenario, about 10 of them grouped into one, remaining 10 are grouped to a few different places. And, the project runs as smooth as silk, narry a single drop out to be heard!!

So, the only difference that I can think of is this: The project that I have with all the dropouts, is basically an OLDER project that I flew in new tracks onto, and more or less used as a template. The project that I mentioned above was built from scratch.


I tested this theory with another older project that I have going, same deal, I flew in new tracks on to and basically used as a template. BINGO, dropouts everywhere. and there’s only FOUR tracks using an Amp Sim.

So, this now makes me more confused than ever. But I’m going to continue testing this with some other new projects that I built from the ground up and did not take from the archive and fly new tracks onto.

I should mention that on my older desktop machine that does not experience dropouts, none of these projects experience dropouts, including the older ones that I’ve flown tracks onto and used as templates.

Ah, I believe the Podfarm software is indeed dongled via iLok.

So, to answer these questions, I always operate at 1024 buffer size, it’s just seems like the sweet spot that I’ve found with my workflow.

And yes I’ve tried going into airplane mode for my sessions, and this doesn’t help at all. the dropouts continue at the same consistency.