No peaking in CPU/Memory usage still I get dropouts in DAW

[bencuri]

I would like to know that if you have a problem with your DAW that you get dropouts or clicks when recording, but you have no peaking issue in the Task Manager, what can it be that causes the issue?

I am on Windows 7, my DAW is Reaper, my Interface is Alesis iO4, and when I set the buffer to 64, I have these problems mentioned above if the Windows settings are on the default. If I follow guides and do music production focused changes, the problems are gone. However I have just noticed that this is not a performance issue. No matter if I optimize Windows or not, I can see no memory and CPU peaking when the problems happen. So what can it be that is causing the glitches?

I am asking this, because the Windows installation that I have is also for everyday activities besides the DAW. But if I need to do the the lengthy changes to make the system optimized for the DAW, that would be quite an annoying practice every day. But it seems even on the default settings there would be enough hardware power to manage things in the DAW, yet the problems are there. I wonder if there would be a simple way to solve this, so I don't need to do too many adjustments, and I could record music and do the everyday stuff besides each other.

For example giving Reaper permanent 1st place priority or something like that?

I have a MacOS installation on the same laptop with Logic. There I never had this kind of problem. I did not need to optimize anything there, just installed the OS and Logic, and it simply works, even with 32 samples buffer. And I don't need to keep things exclusively for the DAW. Can use it for any kind of work, if I need Logic I use that, if I need Chome I open Chrome, etc. No need for tweaks, and no performance issues.

[Drew Stephenson]

It might be that your buffer size is too small. Try increasing it and see if that fixes it.

[bencuri]

Yes, that fixes it, but if I set it larger I can't really record with plugins when I need. The delay starts to be there.

[RichardT]

Try checking your ‘DPC latency’. DPC = direct procedure call.

This will check whether some other processes on your machine are causing delays to the execution of your audio rendering.

I haven’t needed to do this for many years, fortunately, so I can’t recommend any particular product for this, but you should be able to find some if you search for ‘DPC latency checker’.

[SafeandSound Mastering]

Try setting your processor scheduling to "Background Services" that was a thing I believe for Windows 7 - System/Advanced System settings/Performance / Advanced tab select background services.

That was one of the first tweaks as I recall.

[Wonks]

Also make sure that any sample folders are excluded from checking by Windows Defender.

[ajay_m]

Some machines -Dell is a notorious example - have poorly written power management drivers that introduce dpc latency spikes and/or push dpc latency up to the point where small buffers simply cannot be filled and processed reliably.
Other brands can also have issues with other drivers such as WiFi and graphics cards.
You ideally want to see DPC latency well under 1ms and with no spikes.
On top of this dynamic CPU speed changes can also introduce issues. Ensure CPU min and max speed are 100% in the active power scheme.
Core parking is another issue that may require attention, Google for details. Having said all that 64 is really demanding on windows. If you need this small a buffer to get acceptable latency (and anything under 5ms ought surely to be fine) then you may need to review the audio device you are using.
Macs are designed with known parts and so Apple can ensure these kind of issues simply don't occur. But windows machines use such a wide range of hardware that frankly it's a miracle windows audio works as well as it does.

[SafeandSound Mastering]

As far as it being a miracle I am not so sure. I think some simply get an unlucky component that causes trouble. We know graphics cards and their drivers can be culprits.

My hobby machine is a 2600 i7 4 core, so many years old on W10. It was actually an old office machine with a fairly lowly chipset for an i7. It has simply worked and worked very well. 160 track DAW projects completed, tonnes of soft synths over and again and a silly workflow of my own making of using 40 or so carefully tailored effects plug ins (on their own returns) with specific settings per sound, with a PCI RME 9632 in it.

I have run it over and again at 90pct ASIO.

It has a few OS tweaks W10 (W7 before that) and it goes on and on. Only thing I swapped out is 8GB to 16GB of RAM (made a huge difference going from 32 to 64 bit, yes it's that old.) and a new CPU cooler and a CPU Arctic Silver re-paste every 4 years or so to keep things efficiently cooled.

That thing is amazing and by todays standards it's junk right ?

I personally think PC's are truly amazing for what you get for the money.

Sure I get them built by SCAN for mission critical income based work but I use an old dog that motors on with ease for hobby music making and it is literally nothing in PC terms, (a crapped out, ancient office machine ) it just works. (It has a Seasonic Gold PSU to be fair, not cheap.)

I have to say I think USB 2.0 is a downgrade from even PCI. USB2.0 works fine here for what I need but I found PCI extremely robust, even non RME cards just worked without any trouble. (An Emu and an Event Layla whilst they worked for the hobby machine.)

I think you have to be unlucky with hardware / OS config or doing something really out of the ordinary (at least in the vast majorioty of PC installs) for something to screw audio up.

In 2025 a fast PC is ridiculously powerful in comparison (it could be a clear 12 x the speed, maybe 3 x the computational power on a single core than my old dog and then has what 16 or 20 cores !) so why is it that they are still reported as being lesser than an mac etc. I think a lot of people honestly just have no clue what they are doing, maybe they just cannot do details ? (and I am not speaking of the person posting here specifically I mean generally.)

Maybe they do not 100pct dedicate a machine to audio and fill it will a tonne of junk software they do not even know is there or what it is doing. That is probably 1/2 the battle right there. I never install anything non audio unless critical, and then I know what has been installed and if performance nose dives shortly thereafter you know why.

You get to know a methodology with PC's, what to do and what not to do. And the first thing is you dedicate the entire machine for one cause, solely audio.

I am not a PC expert, I know what I need to know though... my experience with PC has been great overall and long may it continue.

I have never personally needed a latency lower than 10-12ms for MIDI keyboard playing input, maybe this is part of why my experience has been smooth.

Just for fun (and my fave CPU comparision now gets blocked due to a security issue/portscan flag)

"Core i7-14700KF outperforms Core i7-2600 by a whopping 896% "

Something is very seriously wrong if a fast new PC today cannot run audio properly.

[alexis]

Try setting your processor scheduling to "Background Services" that was a thing I believe for Windows 7 - System/Advanced System settings/Performance / Advanced tab select background services.

That was one of the first tweaks as I recall.

Pete Brown of Microsoft does suggest:

Tip: Changing processor scheduling to “Background Services” is almost never beneficial to an audio workstation

That was for W10, and he lists some exceptions.

https://devblogs.microsoft.com/windows- ... de-part-3/

[alexis]

Try checking your ‘DPC latency’. DPC = direct procedure call.

This will check whether some other processes on your machine are causing delays to the execution of your audio rendering.

I haven’t needed to do this for many years, fortunately, so I can’t recommend any particular product for this, but you should be able to find some if you search for ‘DPC latency checker’.

+1

https://resplendence.com/latencymon

[SafeandSound Mastering]

Try setting your processor scheduling to "Background Services" that was a thing I believe for Windows 7 - System/Advanced System settings/Performance / Advanced tab select background services.

That was one of the first tweaks as I recall.

Pete Brown of Microsoft does suggest:

Tip: Changing processor scheduling to “Background Services” is almost never beneficial to an audio workstation

That was for W10, and he lists some exceptions.

https://devblogs.microsoft.com/windows- ... de-part-3/

Fair enough Richard, it sure went around a lot that one and for years. I used it and all my machines have worked very well, so it did not appear to harm either.

Though maybe it could be said...

"Changing your OS to the lastest W11 update is almost never beneficial to an audio workstation" There is much online to suggest that audio performance has nose dived according to many anecdotal reports.

Thing with a PC is that as well as component ambiguities which you can clearly get lucky with, USB2.0 has to be many things for many devices and always remain reverse compatible. PCI probably had a slightly less wide range of devices that were designed/had drivers written for it.

I have no idea how these devices (PCI vs USB2.0) interacted with CPU either, if there are specific access circuits/lanes or they share resources in the chipset and CPU. There is a lot going on and I would not know precisely what affects what. With the oft mutliple USB types and connections on a modern PC up to 8 2.0 /3.0/3.2/C, it is easy something starts to share your USB audio devices USB connection without you even knowing.

With PCI, this was not so easy, you often had merely 1 card installed on that dedicated bus. Not potentially, input devices, dongles, HDDs and pretty much anything else USB.

My own personal experience for a few decades is that most PC's seem to work well as long as you stay with tried and trusted norms. (although probably all arguable and as many people have used or recommend other components and manage.) I simply stick with what has continued to be successful for myself in practice, why would you change ? That is the reality I experience afterall.

The way I have seen it, is as follows...

ASUS Motherboards
Intel CPU's (use on board graphics) with a decent chipset.
On machines I build I use slightly upmarket Thermal paste (like Arctic Silver) and do the complex application filling all the little micro faults in the metal with a credit card.
ATI now AMD video cards if you need them.
Top grade PSU's only.

I have used memory of many brands and never had trouble. Mainly Corsair.

I would bet money most people load up their "dedicated DAW machine" with video editing apps, encoding software, various security, utility apps and all sorts of other apps they may think will not have any effect. And probably have it online for surfing as well. I know for sure some run games on it !

Fine, that's your freedom but if audio starts going wonky it will not be a big surprise. It is worth checking your startup apps every now and then to see what maybe running.

I even removed a hard drive cloning software after I installed it.

Dedicated means dedicated to me. DAW's and plug ins for audio and that's it.

That is probably the very first thing to do if your machine starts acting up, uninstall anything not audio related. And keep a desktop record on a document of what you install and if your start having troubles. The more you push anything the more likely to expect issues.

[merlyn]

... Try checking your ‘DPC latency’. DPC = direct procedure call. ...

It's deferred procedure call, and it's the deferring that is the problem. It has to be said that some laptops are just never going to do real-time audio. Some motherboards have SMIs -- system management interrupts -- which put the whole machine on hold while the motherboard gets its ducks in a row.

@bencuri said this machine also runs macOS, so I would think it's a Mac.

[alexis]

bencuri,

Apologies if I missed it, but could you list your computer specs (they may help explain some of your problems)?

Also, if you had a chance to run latencymon (can download for free at that resplendence site I linked to a few posts up), that might help also.

[bencuri]

... Try checking your ‘DPC latency’. DPC = direct procedure call. ...

It's deferred procedure call, and it's the deferring that is the problem. It has to be said that some laptops are just never going to do real-time audio. Some motherboards have SMIs -- system management interrupts -- which put the whole machine on hold while the motherboard gets its ducks in a row.

@bencuri said this machine also runs macOS, so I would think it's a Mac.

Yeah, but remember I mentioned I am running a MacOS (Hackintosh) on the same laptop, and there I don't have these dropout and click issues even at 32 samples buffering that I have in Windows at 64. So in case the motherboard is limiting something for physical reasons, that should be a limiting factor in the MacOS as well, shouldn't it? Because you are now talking about a hardware feature not a software feature.

[Wonks]

No, it’s software. Normally drivers of some sort but sometimes how Windows interacts with the hardware.

[bencuri]

Try setting your processor scheduling to "Background Services" that was a thing I believe for Windows 7 - System/Advanced System settings/Performance / Advanced tab select background services.

That was one of the first tweaks as I recall.

Pete Brown of Microsoft does suggest:

Tip: Changing processor scheduling to “Background Services” is almost never beneficial to an audio workstation

That was for W10, and he lists some exceptions.

https://devblogs.microsoft.com/windows- ... de-part-3/

I have to argue this. As I mentioned I can set my Windows to make Asio4all and Reaper run smooth with 64 samples buffer, after going through a lengthy series of tweaks. Personally what I noticed is if prioritizing Background Services is switched off, the tweaks don't work. As soon as you select it, the clicking goes away. So my experience is that in my case it is definately beneficial to select that option. I am on Windows 7 however, whether this would be a case on Windows 10 or not, I don't know.

[bencuri]

bencuri,

Apologies if I missed it, but could you list your computer specs (they may help explain some of your problems)?

Also, if you had a chance to run latencymon (can download for free at that resplendence site I linked to a few posts up), that might help also.

So this is a Probook 6570b. CPU is 3210M, and there is 8GB memory.

There are two SSDs in it: the SSD on the main storage slot is for Windows, it was installed in Legacy mode. There is another SSD in the Upgrade Bay, for a MacOS 10.11. That was installed using UEFI. The BIOS system setting is UEFI LEGACY Hybrid for this reason.

The BIOS version is an old one, from 2012. The latest would be a 2019 one, but I am afraid of installing it, because I am not sure whether it will ruin the Hackintosh installation. The system of the Hackintosh side was build following a 2015 guide, that was simple, but is not available any more. If I need to redo it,I am not sure if any guides would support the new BIOS at all, and new guides are very complicated. So I am kind of stuck in that aspect.

LATENCYMON:

This is where I got part of the solution, switching off the WIFI. Because the message I get is this, if I use my Windows in untweaked mode:

"Conclusion: Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. At least one detected problem appears to be network related. In case you are using a WLAN adapter, try disabling it to get better results. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
"

The network part of the warning goes away if I switch off the Wifi. But even if I do every tweaks I need and can start setting Asio4all to 64 samples buffer, This part of the warning remains:

"One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates. "

This even persists if I add a Disable Throttling setting to the registry manually.

And as I mentioned the problem is I don't dare to update the BIOS. If my Hackintosh installation stops working, that would be catastrophic, because I use it on everyday basis. Can't risk not being able to run it.

Not sure if it matters:

-I have no Updates installed, Windows in in its original state, except for some elements I installed manually from the Microsoft Update library, that some apps needed.

-My Windows installation is very old, I ran it for years on a faulty HDD, with having only 70GB from the 500 for years, that caused system collapses due to data having been written onto bad sectors I guess. When I got the new SSD, I cloned my system as a system image. I am not sure if this can cause performance issues? So that I cloned the faulty drive as is.

And these are the core and thread usages from Process Explorer while recording in Reaper:

[Pete Kaine]

I would bet money most people load up their "dedicated DAW machine" with video editing apps, encoding software, various security, utility apps and all sorts of other apps they may think will not have any effect. And probably have it online for surfing as well. I know for sure some run games on it !

"Ahem" (tabs out of Ableton, shuts down Steam, GOG, Epic and Discord) no idea what you're talking about...

So this is a Probook 6570b. CPU is 3210M, and there is 8GB memory.

With CPU Mark result of 1500 on the single core testing result, that would be lower than where I would look as a baseline entry point for having a reasonable amount of overhead in terms of fx processing in modern terms.

Not a problem of course if you've frozen your effects list for a good few years, but if you're installing the latest plugins I can see that running out of overhead quickly on the lower buffer settings and why it might behave better at higher settings as others have noted. Still, you do appear to have a underlaying DPC issue as well which is no doubt also eating into that processing overhead.

The BIOS version is an old one, from 2012. The latest would be a 2019 one, but I am afraid of installing it, because I am not sure whether it will ruin the Hackintosh installation.

I'm not sure it would help you if you did. There's various power state settings which are advisable to disable when tracking down DPC spikes and whilst easy to access on a desktop system, most laptop firms choose to hide them entirely. If you can't find them on your current BIOS, I wouldn't really expect them to be in the later one either. C-states & EIST settings are the ones you would look to disable, along with anything else that looks like it might limit power.

"One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates. "

This even persists if I add a Disable Throttling setting to the registry manually.

It's probably still being overridden by the settings I note above if you can't see them.

-My Windows installation is very old, I ran it for years on a faulty HDD, with having only 70GB from the 500 for years, that caused system collapses due to data having been written onto bad sectors I guess. When I got the new SSD, I cloned my system as a system image. I am not sure if this can cause performance issues? So that I cloned the faulty drive as is.

DPC is a measurement on how long it takes any given process to access the CPU within a processing cycle. I wouldn't expect corruption to manifest in a DPC issue, but given poor drivers can spike it, then a corrupted driver might be to blame but it's a bit of stretch.

Rerun the DPC Latency test for 10 mins. Stop it, grab a screen shot of the main tab and the Drivers tab, but sort the drivers tab by "highest execution" before doing so. Whilst the results can often be a bit vague, I might be able to hazard a guess at what's causing your spike from that information.

[merlyn]

Yeah, but remember I mentioned I am running a MacOS (Hackintosh) on the same laptop, and there I don't have these dropout and click issues even at 32 samples buffering that I have in Windows at 64. So in case the motherboard is limiting something for physical reasons, that should be a limiting factor in the MacOS as well, shouldn't it? Because you are now talking about a hardware feature not a software feature.

Yes, SMIs are a hardware feature. I would have thought that you were pretty lucky to find a Windows laptop with hardware compatible with macOS. e.g. Apple don't do Nvidia after a falling out some years ago. You have found that Core Audio is more stable than ASIO. Core Audio uses a safety buffer (which adds a small amount of latency) and a delay locked loop, which means less buffer over- or under-runs resulting in pops and clicks at the price of a small amount of latency. The question does arise -- if macOS is working why not use macOS?

[alexis]

..
Rerun the DPC Latency test for 10 mins. Stop it, grab a screen shot of the main tab and the Drivers tab, but sort the drivers tab by "highest execution" before doing so. Whilst the results can often be a bit vague, I might be able to hazard a guess at what's causing your spike from that information.

I'm glad you quote that, thanks Pete.

I thought one had to run it for hours to be sure, 10 min is much nicer.

One question I've always had - in situations like this does one run LatencyMon with the DAW on or off?

[Pete Kaine]

I thought one had to run it for hours to be sure, 10 min is much nicer.

One question I've always had - in situations like this does one run LatencyMon with the DAW on or off?

Pretty much everything is going to fire in that time period that may be to blame, so it should be long enough. 20 mins unattended may start to see some background housekeeping occur (drive cleanup optimization, updates, virus scans etc..) but you can look at those in a second instance once the 10 min score is clear.

To same end, your chief concern is getting the OS as flat as possible first of all, so you test it on the desktop without anything running. If you then go on to find it only spikes with the application open when it wasn't doing so on the desktop, then you at least know you need to look at your application settings and optimizations rather than poke around in windows any further.

[alexis]

I thought one had to run it for hours to be sure, 10 min is much nicer.

One question I've always had - in situations like this does one run LatencyMon with the DAW on or off?

Pretty much everything is going to fire in that time period that may be to blame, so it should be long enough. 20 mins unattended may start to see some background housekeeping occur (drive cleanup optimization, updates, virus scans etc..) but you can look at those in a second instance once the 10 min score is clear.

To same end, your chief concern is getting the OS as flat as possible first of all, so you test it on the desktop without anything running. If you then go on to find it only spikes with the application open when it wasn't doing so on the desktop, then you at least know you need to look at your application settings and optimizations rather than poke around in windows any further.

Gold, thanks, Pete!

[bencuri]

Rerun the DPC Latency test for 10 mins. Stop it, grab a screen shot of the main tab and the Drivers tab, but sort the drivers tab by "highest execution" before doing so. Whilst the results can often be a bit vague, I might be able to hazard a guess at what's causing your spike from that information.

Sorry for the delay I was on a journey couldn't do this meanwhile.

I ran this test. The Wifi was disabled in BIOS, Virus Scanner was not loaded, prioritizing background services was on, energy management on high performance. This is just Windows running and the basic services.

[Pete Kaine]

The DPC result itself is fine, great even in fact. Your failure is ISR related, something on the hardware side is stalling the system when it's a failure on that specific part of the test.

https://www.resplendence.com/latencymon ... pt2process

The test results don't really give a smoking gun, unfortunately, it's not something that's reported in full by this test app. If you go into stats tab after rerunning the test again, it'll tell you the "measured interrupt to user process latencies" result at the top (figures only, no causes) and as link above note it's related to the section directly below it, although whilst that section (reported ISR's) will give some clues, it tends to show the highest result from what is going to be a big pile of measurements that it doesn't otherwise show you.

General advice would be unplug any new hardware you've plugged in, but being a laptop I guess there's not a whole lot going on in that regard. You can take a look at the "reported ISR's" and update/disable whatever comes off as highest and see how far that gets you, but it's likely to be a game of whack-a-mole.

Sorry, probably not a lot of help, but if it's been fine for a few years then now then I would be looking at removing recent hardware changes or new kit you've plugged in. If it's already stripped back from extra kit and hubs, then it seems like a hardware problem at some level, be that driver or otherwise.

[alexis]

... prioritizing background services was on ...

Would prioritize foreground services instead and see if it makes any difference, consistent with Pete Brown's suggestion in the link I posted above.

No harm done if it doesn't improve anything (being a super easy change to make), and easy enough to reverse if you like.