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

[ajay_m]

Unfortunately these kind of DPC latency issues can be related to vendor-specific drivers or vendor-specific code that ends up being called by drivers that is poorly written. Some vendors - Dell for instance - are notorious for this problem and it can be very difficult to resolve this for a particular brand of machine.

In some cases it has proven possible to resolve issues by disabling networking, or by disabling various power management features including in some drastic cases, removing the battery device in device manager, which seems to stop some problems with Dell laptops. You could try booting in safe mode and re-running the DPC latency test and see if at least in that configuration, you can get glitch-free results from the test, because at present for sure those results certainly will indicate serious problems.

[Wonks]

Ataport.sys on looking it up on Microsoft seems to be hard drive related, either the drive or the interface chips.

You could always try and find the latest hardware drivers for your motherboard, or reload them if the same version(s) as you have.

[ajay_m]

I did some googling and a lot of people have suffered this but without any clear resolution. However, to summarise the things I would try

1. All AV disabled. Note that some AV software installs filter drivers which you really, really do NOT want on your system. Have a look with the 'fltmc' utility and compare with what's expected on a clean imaged machine.
2. Ensure you are only using the standard Microsoft drivers for core hardware and not vendor-specific drivers which often introduce problems. You only want to use a vendor-specific driver if the device needs it.
3. All network interfaces disabled (for now, you can turn them back on when you've eliminated them as a cause of problems)
4. Power scheme set to min/max CPU 100% and if there are BIOS options regarding Speedstep, disable it.
5. Disable hyperthreading if the BIOS lets you.
6. Download Crystal diskmark and benchmark your disks. Do they perform as expected? (plenty of comparison results to check against). Never hurts to run chkdsk on all drives too, is everything absolutely hunky-dory?
7. Disable core parking (registry setting, should be plenty of online material on this)
8. Download Sysinternals autoruns and find out what's being loaded at startup. Winnow out stuff you really don't need by disabling services etc. that aren't essential. Plenty of information out there on this.

Fooling around with task scheduling priorities will not help and it will just make things less predictable. The Windows task scheduler is not the cause of your issues here.

I would though be thinking about replacing an elderly system. Over time incompatibilities and issues will multiply. As the saying goes. "If at first you don't succeed, try, try again. Then give up. No use being a damn fool about it"

[Pete Kaine]

Ataport.sys on looking it up on Microsoft seems to be hard drive related, either the drive or the interface chips.

You could always try and find the latest hardware drivers for your motherboard, or reload them if the same version(s) as you have.

That's the result underneath the faulting indicator, at 54μs it's already performing exceptionally well... which is outlining the problem with what I was noting about there not being a smoking gun in terms of individual ISR metrics. If that's the highest problem device and it's appearing to be extremely well behaved already, it has to be something else in the stack or some kind of interaction thats' not being attributed to any given device.

AJays' list above is the sort of thing I'd suggest for a DPC problem, but this doesn't appear to be a DPC problem and the fact it's been working for years already suggests its not something that would be covered by normal tweaking. Certainly, give them all a try, but I'd be more inclined to lean towards a failing bit of kit, or something affected by a large update (service pack sort of level) that's replaced (or failed to cleanly replace) a driver for a key bit of hardware. The fact this is W7 makes that a bit more unlikely as there hasn't been a major SP release in years.

The other problem is that this is a laptop, so chances are most of the BIOS adjustments you'd normally look to make in this scenario are going to be locked out. If anything was majorly problematic in the BIOS then it would have reared it's head on first install, years ago. It's why I was more thinking along the lines of figuring out what has changed within the install or in terms of connected kit and why that is.

*edit* maybe I'm the one misunderstanding this setup... I guess my question at this point is how long has this windows 7 install been on the laptop?

Is this a recent reinstall, or is this an OS install that's been on there for years already?

[ajay_m]

Ok. This is my day job, so a few comments.

DPC latency refers to deferred procedure calls. A DPC is queued and then ultimately dispatched and processed. This is done so that the calling thread will not block waiting for the actual operation to be performed. Then another thread will ultimately pull the DPC request off the queue and service it.

DPCs are common in time-critical interrupt service routines because rule #1 in servicing an interrupt is to get in and out of the service routine as quickly as possible, to avoid issues where other pending interrupts don't get serviced promptly. It's like the runways at Heathrow; planes need to occupy them as briefly as possible so as not to clog up the whole system.

If a DPC request is queued but not dispatched and processed in a timely manner, then audio glitches will definitely occur because these requests are time-critical. So if I queue a request to get some data from memory or disk for my buffer and I don't get it in a timely manner, you're gonna get a glitch.

The DPC latency results above show that at times it is taking up to 15,000 uS or around 15 milliseconds from the time a DPC request was queued to the time it was dispatched and processed.

The 54uS time referred to is the time taken to actually finally get round to processing the request, however the critical issue is the huge intermittent delay in dispatching queued requests. This is generally caused by device driver writers misusing kernel synchronisation objects and causing other threads/processes to stall because they block on the synchronisation object.

This generally occurs in vendor-specific code because the skill of the developers in writing driver code is not as high as Microsoft's engineers. Driver code is very complex and demanding stuff and requires that the developer has an intimate knowledge of both software and hardware. In many cases vendors contract out firmware/driver development and the developers may be working with incomplete or inaccurate hardware documentation as well. Developers use synchronisation objects such as mutexes, critical sections, and spinlocks etc to ensure that data being modified is done 'atomically' and not corrupted by another thread getting scheduled and trying to change the same data before the first thread has completed the update.

Because in some cases Microsoft standard drivers need to communicate with vendor-specific code, it isn't therefore the case that a generic driver like ATAPI.SYS is necessarily the cause of the fault, but the DPC latency tool can't probe beneath the driver level so the best it can do is attribute the delay to the driver at the top of the call stack.

A good machine will generally have DPC service times in the order of 200uS, but as long as these are reasonably consistent and less than 1mS or so, all will be well. But when service times go all over the place, as they do here, this causes major problems because obviously a 15mS stall is going to play havoc with audio processing.

Antivirus software can be a major problem because a lot of it relies on 'filter drivers'. A filter driver intercepts all the requests made to a lower-level driver, such as a disk driver, so that the AV software can check to see what the request is and potentially intercept malicious software. However, there's no easy way to track time spent inside filter driver code and it will be allocated in general to the whole stack of drivers (there can be multiple filter drivers in a 'chain'). Some vendors - McAfee would be a prime example - are particularly problematic.

Windows Defender tends to rely mostly on the Windows Event Tracing subsystem rather than filter drivers to try and track malicious activity, so it does tend to have less impact in this area. Nonetheless, any AV software is always going to interact in unpredictable ways with vendor-specific code so you want to be very careful about using AV software in any real-time environment.

[bencuri]

*edit* maybe I'm the one misunderstanding this setup... I guess my question at this point is how long has this windows 7 install been on the laptop?

Is this a recent reinstall, or is this an OS install that's been on there for years already?

It has been installed at around 2020. And no updates were done. Windows 7 Ultimate SP1, as installed from the DVD, plus drivers from the HP website. Only a bunch of updates were added manually.

There is no newer version of the chipset drivers.

Let me emphasize again: the audio recording at low buffer works. After doing certain steps (some you have just mentioned above), especially switching to background service prioritizing, setting min processor performance to 100% and switching off Wifi solves the problem.It is just too annoying to do all this on an everyday device every time I want to record. If I boot into MacOS on the same laptop, nothing like that is needed. Of course you can say this is how you can do it. But all I want to investigate: what causes the problems mainly, maybe it is just one simple segment that is malfunctioning. Because even if I optimize Windows, Latencymon still gives the same results. So everything is OK on the recording, but Latencymon still reports the problems. Maybe there is some underlying problem, and if I could solve it, I wouldn't need to do so many tweaks to be able to use low buffer settings, and can just record whenever I want.

In this topic a similar problem was discussed and solved, but in Windows 11. I chacked the command for Windows 7, and those parameters don't exist in my Windows version:
https://forum.cockos.com/showthread.php ... ost2838098

Someone else recommends to use this instead of Asio4all:
https://vb-audio.com/Matrix/index.htm

[ajay_m]

If latencymon reports a problem as severe as this then you are just dodging bullets all the time. For instance you may well be able to record without glitches but not play softsynths. A system with DPC latency values like this is never, ever going to perform reliably under all scenarios. My Lenovo laptop reports consistent 200uS DPC latency and there are no glitches at any time, whereas I've had a couple of Dell machines that were just terrible, much like the screenshot you shared.

If you are still seeing these glitches even with the reconfiguration you made, then the root problem is still present and you are just wasting your time, in my opinion.
I'm assuming, by the way, that you DO see these figures even with the remediations you took. If NOT, then my primary suspicion will be the wifi drivers and especially wifi autoconfig, which kicks in every minute to examine used channels in the vicinity. If so, then purchasing an external wifi dongle and switching to that may well resolve the issue. A lot of laptops have horrible cheap and nasty wifi adaptors that were the lowest cost bill of materials that the laptop vendor could conjure up. I have found TPLink dongles to work pretty well, and they are not expensive. The ATAPI reference in the screenshot is just to ISR service time and irrelevant, that is not the metric causing an issue here.

[alexis]

...
Let me emphasize again: the audio recording at low buffer works. After doing certain steps (some you have just mentioned above), especially switching to background service prioritizing, setting min processor performance to 100% and switching off Wifi solves the problem.It is just too annoying to do all this on an everyday device every time I want to record. ...

That is what I do, and more (I also go through the hassle of turning off OneDrive and DropBox sync, and I think I have one or two others I turn off), before doing DAW work, especially recording audio.

It all works, but I agree - what a pain in the neck!

I do all this manually, and am resigned to it being part of my DAW process on this system (oh, and don't forget to turn things back on when done!). I have looked at alternatives, including using ChatGPT to help me learn to write a script to simplify the process, but that never did work 100%, so I'm back to doing it manually.

You'll see in my specs I have a very old computer also. I have updated Windows, interface drivers, etc., maybe that will help a bit in your case. Be sure to back up what you've got before making any changes like that, though!

[bencuri]

Well, that's it, then. If I can't solve it better then I can't.

But at least now I can record in Windows as well with Software Playthrough. Before doing the tweaks I couldn't use my guitar plugins with the 64 samples buffer when recording, at least now I can. I can even go down to the unofficial 32 samples by modifying the registry. That is already an advancement. Will try to test this further however if I get a spare drive and can use clean installs of OS's.

[bencuri]

Just some feedback about this issue, I though some may find it useful:

So just to refresh your memory, the problem here was that if I set my driver to 64 samples that is the minimum supported, lagging will appear. The System is Windows 7 Ultimate 64bit, DAW is Reaper and my device is Alsesis iO4 with Asio4ALL as "factory" drivers.

The exact symptom is that when you set the buffer to 64, you can still play with software playthrough, but as soon as you start a recording, lagging will appear. You need to choose 128 to get rid of it.

I could solve this by doing some common tweaks (performance mode, background services priority, disable Wifi). And that way it works even at 32samples. No lagging.

Today I put another drive into my laptop, installed Win 10 on it. It is a fresh install, only the DAW was added and Asio4ALL plus a few plugins and plugin managers. The result: no matter what tweaks you do, you cannot go down below 128 samples at the buffer. As soon as you do, lagging appears.

This is kind of interesting. Previously I complained about that you need to do complicated tweaks to get the laptop work without lagging, this time, with the feshly installed Win 10, you cannot even achieve the same with tweaks. The Win 10 is on a HDD though. But I guess when you just play something, and do not record, that should mean no problem drive-wise. However I get the lags even if I just play something.

[Pete Kaine]

Win 10 was designed for SSD's, so I can see why that would be a problem given it's a horrible user experience when run off a HDD.

It'll run pre-fetch/search indexing in the background which tend to chew both drive and processing time. Have you disabled both?

[bencuri]

I have some new findings in connection with this topic, I decided to share it, some might find it useful.

- Win 7 on SSD, Reaper, Alesis iO4 interface with no factory drivers, so Asio4all is used. Latencymon reports that there are serious latency problems. And indeed, I need to set the buffer at least to 256 if I want to avoid dropouts. With the usuall tweaking of the system settings, Latencymon still reports latency problems, but yet I can go down to as low as 32, but redoing the settings all the time is not very convenient on a computer used for other taks as well.

- Win 10 22H2, final release on HDD, same setup same laptop: Latencymon reports NO PROBLEM regarding latency!!!, values measured are well in the green level. Yet cannot go lower than 256 as buffer setting even with tweaking. Just an interesting fact: on the same laptop, when OS X was installed, I could run this setup in Logic on USB HDD as system disk with no issues at the 32 buffer setting.

- Today back to the Win7 version of the setup, Audient iD4 as interface, old audient drivers installed (the first official version), no system Tweaking done, so settings are what you get from Windows 7 as default: NO DROPOUTS with the buffer set to 64. The only problem is I don't find it in the registry where you could force the buffer to go down to 32 like with Asio4all.

So I concluded 2 things:
- You have to be careful with the reports of Latencymon.
- The major problem is very likely Asio4all.

Some suggested to use VB Audio Matrix instead of Asio4all. The only problem is that I cannot find a simple description how to set it up for a USB interface. The only video I found on Youtube is going into the details too much, I get lost when I am listening to it, it is way too complicated. It would be easier if there was a description focusing on where to click and what to set when you want to get your interface working. I am not interested in other connection possibilities and complicated device setup solutions. Those are the things that I don't understand.

[Wonks]

LatencyMon simply tells you problems with system drivers taking up too much processor time.

It doesn't have anything to do with your audio driver latency.

If you don't cure LatencyMon issues (if you can), then you don't stand a chance of getting low latency with your audio interface.

If you do cure the problems, then you are then left with how good the interface drivers are. Not all (especially on older interfaces designed when computers were far less powerful) have very low buffer settings in their control panel. And Alesis left it up to Asio4All to provide a lower latency with Windows. Alesis had a habit of coming up with good ideas and then not putting enough effort into developing the product before release.

If you want lower latency, then you'll be much better off changing the interface if you can afford to.

It's not a great interface, especially wh

[James Perrett]

- The major problem is very likely Asio4all.

It took 15 posts in this thread before you mentioned that you were using ASIO4All. If you don't give us all the relevant information then we can't really get to the root of the problem.

If you want high performance then don't use ASIO4All If the interface doesn't have native ASIO drivers then it simply isn't designed for music use.

[bencuri]

It was mentioned on the previous page:

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:

Okay, but on Mac OS on the same laptop the same interface works fine. Moreover it has less problems with high gain signals on input than some brands referred to as TOP of the cathegory. I already purchased the Audient iD4 but its input is very problematic. But that is another story. That's why I stick to the Alesis. It tricked me less times than the Audient. The problematic feature is that I need to reboot to MacOS every time I want to record or check a music project.

[James Perrett]

The Alesis is probably a perfectly good class compliant interface but currently Windows doesn't properly support class compliant interfaces with high performance drivers. So for Windows you are reliant on Alesis supplying a suitable driver - which they don't.

ASIO4All is not suitable for serious use so you'll need to use your Audient on Windows and the Alesis on any operating system (like Mac or Linux) that properly supports class compliant interfaces.