DPC Latency - Tech Help Required

[Matthew Carr]

Hi All, afraid I need some technical help.

I (unfortunately) just bought a dell laptop (Lattitude 5480) for use with cakewalk. On paper, this thing is a beast : i7-7820HQ processor, 16 Gb Ram, Pcie(4x) SSD. It's a great laptop, very fast and capable, but turns out it's completely unusable with any audio program due to DPC latency

LatencyMon shows the culprit as ACPI.sys  - I'm getting latency readings of over 2500uS, which results in lots of audible clicks and pops with reasonable ASIO buffers (256)

I've done all the usual: disabled c states, turned off speed-step and turbo-boost in Bios; Set all power plan settings to max performance; Disabled network, on board audio, camera, microphone array etc in device manager - but nothing works. The only thing I can think of now is  to try and set processor affinity so cakewalk only runs on cores 2,3 & 4 - the DPC spikes seem only to occur on core 1. Is this possible, and does anyone have any experience or knowledge of doing this? I did attempt creating a shortcut that set the processor affinity using this article :https://www.eightforums.com/threads/cpu-affinity-shortcut-for-a-program-create-in-windows.40339/  but without much success.

Is it possible to restrict Cakewalk to only use certain cores, and is it a viable technique to get around DPC Latency issues?

Any advice gratefully received, as this is starting to look like an expensive mistake... 

[Jim Roseberry]

There is no work-around for extremely high DPC Latency.

It has to be addressed at the source.

 

FWIW, Disabling TurboBoost won't solve DPC Latency issues.

 

If you've updated the motherboard's firmware, updated all drivers, and updated Win10... you're out of options.

 

When dealing with a general-purpose machine, you have to keep the target end-user in mind.

The typical user of that laptop would never know it suffers from a several millisecond "hiccup" in data flow.

For someone wanting to use it for DAW purposes, that small hiccup in data flow results in an audio glitch or dropout.

Lets say you want to run your audio interface at a 64-sample ASIO buffer size (44.1k).

The machine has 1.5ms to process/fill the next ASIO buffer. 

If a driver is monopolizing the CPU, the next buffer won't be processed/filled in time (resulting in a glitch/dropout).

 

The typical user cares far more about extended battery life than ultimate performance.

The power-management necessary for extended battery-life is diametrically-opposed to what we want in a high-performance DAW.

With Laptops, power-management is the source of many DPC Latency issues.

 

[Jim Roseberry]

Laptops that are particularly good for DAW purposes are expensive, large/bulky, and have short battery-life.

IOW, The general-purpose user would hate it.  ?

[Matthew Carr]

Thanks Jim, Everything is updated to latest versions, so I'm out of options there. 

13 minutes ago, Jim Roseberry said:

There is no work-around for extremely high DPC Latency.

I'm a bit deflated by that. The laptop has 4 cores, and only one core is being impacted by high DPC latency - surely if the audio app only runs on the cores not impacted, it wouldn't be interrupted by the process which takes a takes a long time to complete. Or am I being too simplistic?

 

[Jim Roseberry]

ACPI.sys is power-management related... and DPC Latency issues with that culprit often can't be resolved.

 

Unfortunately, it's not as simple as assigning your DAW software to "unaffected" cores.

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-threaded-dpcs

[Robert Bone]

I had an issue with the latency spiking on a laptop - I removed the battery pack, and just kept it plugged in while using it for music performance/production.  This instantly resolved ACPI issues I was having, though it did leave me exposed to instantly shutting down if the power connector got bumped too much, or disconnected.  I ran for well over a year in this fashion.

Might be worth a shot.

By the way - not related, but seeing you are running a laptop, this jumped into my head - lots of folks have issues when their WiFi is enabled, and they either temporarily turn WiFi off using, usually, some sort of function key on some laptops, or a hardware switch - and if neither is present, they would temporarily disable the WiFi drivers in Device Manager, right before starting a Cakewalk session, and would enable the WiFi again after finishing their Cakewalk session.

Bob Bone

[Gswitz]

 

In case it helps.

[Starship Krupa]

What Bob Bone said is a clue: ACPI.SYS is part of what controls your processors to give your laptop longer battery life. Take it out of the picture and you get performance back.

Me, I refuse to believe that there is no way to wrest control of the hardware away from the OS, although you may need the help of Google searches and maybe a 3rd-party utility.

I have had good luck with Process Lasso.

Rather than having it running all the time, I set it up to kill all the processes that I didn't want running while I'm doing DAW work, then start it before I do a Cakewalk (or whatever) session. The default view is to have its activity log visible, and I still remember this one session where it delivered a repetitive utter beatdown upon the poor Apple Mobile Device Service, which I had excluded. It kept trying to start up, but Process Lasso would have none of it. It went on, every 200mS for about 15 seconds, which is forever in computer time, until the Apple Mobile Device Service just stopped trying.

Edited August 3, 2019 by Starship Krupa

[Matthew Carr]

Thanks All, some good advice given - I might be making some progress but need to do more testing.

I'd read that the battery system could cause ACPI.sys latency in a laptop, so I disabled the 'Microsoft ACPI-Compliant Method Battery' driver under battery settings. Seems to make it appear to windows there is no battery installed, so easier than physically removing the battery. That did seem to help somewhat, but still was getting spikes (wifi / ethernet was disabled)

I then tried setting the processor affinity for Cakewalk.exe to cores 2,3,4 via Task Manager, and even though latency Mon was still reporting high DPC on core 1, audio seemed to be OK with a buffer of 128.  Unfortunately, doesn't seem to be a way to set processor affinity for APCI.sys (even using Process Lassoo) and as I want to use this laptop in a live setting, I'd be nervous that ACPI.sys might for some reason  move off core 1 and wreck things - although I haven't seen that to date

Guess I need to do more testing, to see if I can get ACPI.sys under control, or build my confidence up that setting processor affinity will do the trick. 

Either that, or I sell the laptop and keep lugging my racked I7 desktop to gigs.. ?

[chuckebaby]

Why not purchase an inexpensive USB soundcard, Like a Focusrite Solo ?

And have you tried WASAPI or ASIO4ALL ?

[Matthew Carr]

Thanks Chuck, but I'm using an external USB Soundcard via ASIO - the DPC Latency is caused by the laptop, not the interface.

[PeterMc]

Is this relevant? Looks like the latest Windows 10 version 1903 (May 2019 update) caused DPC latency spike problems, and there is an update to fix it. I'm hoping this might help.

Cheers, Peter.

 

[Jim Roseberry]

At the risk of repeating:

If the machine suffers from high DPC Latency, there is no working around it.

It has to be solved at the source.

No audio interface, no setting core affinity, etc.

Read the details here:

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-threaded-dpcs

 

With many cases... especially when it's ACPI (power-management) related, there is no solution.

The only solution is to replace said hardware (in the case of a Laptop, NUC, All-In-One) isn't possible.

[azslow3]

There are many reports in the Internet about "DELL latency" and ACPI in particular. I also have DELL (older XPS) and it also reports "no go" in Latency Monitor, sometimes from ACPI, sometimes from Wdf, etc. When started at bad time...

I mean to conclude that is really persistent, completely update the computer and wait till MS has finished all pending tasks. Can take a while (hours) when connected to the internet and several reboots. Once the system is finally "idle" (no pending tasks, almost 0 CPU use), take it offline. Wait for a while and then start Lantecy Monitor, without doing anything else (not starting any application). If you still have problems in such environment, there is something seriously wrong. If there is no problems when completely idle but there are problems when you start applications, that is a different case.

As I wrote, if I start Latency Monitor without "preparation", the picture is bad. But I can easily keep the buffer 64 without any glitches when I need that (RME+REAPER).

I do not think ACPI has troubles by itself (as most MS own drivers), something should "helping" it to do this. That something can be hard to find. But disabling all background programs you do not need and unused/not important devices can eliminate the trouble. Even if there is no logical correlation, modern computers are complicated devices with hundreds of components. And all these components are "fighting" for some shared resources.

One of the tricks I was not aware until recently: https://forums.guru3d.com/threads/windows-line-based-vs-message-signaled-based-interrupts.378044/

 

[Jim Roseberry]

41 minutes ago, azslow3 said:

As I wrote, if I start Latency Monitor without "preparation", the picture is bad. But I can easily keep the buffer 64 without any glitches when I need that (RME+REAPER).

The reason you see this is due to CPU throttling.  

When the machine is under heavier load, DPC Latency is lower... because clock-speed is higher.

If the machine has major issues with DPC Latency, putting it under heavy load won't solve the issue.

 

Power-management necessary to achieve long battery-life is diametrically opposed to configuration for maximum performance.

That's the heart of the issue.

 

If you look at any of the top performing custom built laptops, notice that they're *all* using Clevo shells.

They're expensive, bulky, and have extremely short battery-life.

Physics... of such a tight space make it a complicated balance.

If you're strictly talking off-the-shelf laptops, Apple (OSX on the MBPs) does a better job juggling the above than any off-the-shelf PC laptop.

Custom Clevo's smoke the MBPs... but that's another topic.

 

[Jim Roseberry]

54 minutes ago, azslow3 said:

One of the tricks I was not aware until recently: https://forums.guru3d.com/threads/windows-line-based-vs-message-signaled-based-interrupts.378044/

If you don't know what you're doing, be careful when switching!

Some devices don't work (at all) with MSI... and can cause your machine to BSOD.

Other devices (like RME audio interfaces) will appear fine... until you try to use it (and realize it's not actually working).  

Video cards and most of the core hardware work fine with MSI

Audio interfaces (dedicated and onboard) and Firewire controllers often don't work with MSI.

[azslow3]

35 minutes ago, Jim Roseberry said:

The reason you see this is due to CPU throttling. 

My point is that DPC latency can be influenced by background activity. May be good optimized for audio PC/Notebook is rock solid when MS updates its drivers... but I have hard time to believe that is always the case ?

So during update/startup/malware checks/telemetry collection/(100 more tasks) I observe high DPC. But that does not bother me much as long as after all that is done I can use my notebook without latency and clicks (while not really optimizing it for audio).

With MSI I also have failed to change the mode to major components. But many "tiny" devices, like mentioned in the linked post, could be switched. That "un-share" interrupts, also for major components. I guess the effect is system specific, but share interrupts was never good. In the worse case there is simply no difference in DPC, but since there is no known negative sides (as long as the device/driver is able to work at all), why not set it just because that is possible.

[Robert Bone]

I certainly do not understand the ins and outs of DPC latency (much at all).

My earlier post relayed my own experience, where nasty latency spikes instantly went away, on my Dell laptop, which had a battery pack that was beginning to get long in the tooth, the moment I removed that battery pack, and the ACPI drivers were either disabled or did not load (cannot recall which).

I ran that laptop for about a year without out its battery pack, and as long as it stayed plugged in, everything ran wonderfully, with an ASIO Buffer Size of 128.  This was approximately 85 performances over that year-long period, in addition to rehearsals with the band, and practice at home, plus my working on Sonar projects in between everything else.

Bob Bone