Getting 64-sample audio latency on Windows 8

I recently spent some time setting up a new audio rig with my Presonus Audiobox USB audio interface. I won’t promise that you’ll get the same results I did, but I’ll share what I learned along the way to getting lower latencies with my setup.

I’ve written a little bit before about the state of USB audio in Windows. It kind of sucks actually, and it seems to suck a little bit more on Windows 7 than it does in Windows 8, which is kind of convenient, as I’d rather go with the later version of Windows if possible. Note that the dpclat tool gives false readings on Windows 8. This caused me pause for a while since the average reported DPC latency will be very high with respect to Windows 7. However I wasn’t seeing as many problems as I would have expected for this high latency. I found a reference to dpclat being updated for Windows 8 support and that the readings are artificially high due to a change in the way Windows reports the DPC statistics. Check out this Anandtech thread for details.

However, the driver situation on Windows is pretty awful when it comes to getting good performance. The way the Windows kernel works is that it serves up time slices to various processes and if everything in the path of your audio data doesn’t get its CPU time before the data in the audio interface can be processed you lose some incoming data, resulting in a loud pop.

Actually, that’s essentially the way all modern operating systems work. However, many legacy hardware devices such as ps2 keyboards are written very inefficiently and there are some power-saving features of ACPI (advanced configuration and power interface) that will really kill performance if they aren’t disabled.

The Mac works with USB audio without a hitch out of the box in my limited testing. On Windows the onus is on us to figure out which drivers or devices are killing our performance. This is a tedious process of using LatencyMon to figure out which drivers are taking most of the CPU’s interrupt handling time and deferred procedure calls. These are important because once a driver is in a DPC or is handling an interrupt it cannot be preempted. So if a driver is spending a lot of time handling interrupts, there is a good chance that at some point the audio driver will need CPU time to flush its buffers and not be able to get it because the CPU is servicing non-preemptible requests.

So on my system there are a few things that made the biggest difference. These things will probably be different on yours. I have done this process on two different machines with different hardware and had two very different sets of drivers that were misbehaving.

In one case “ACPI Compliant Control Method Battery” was a huge culprit. The driver ACPI.sys was scheduling a lot of DPCs according to LatencyMon and I couldn’t figure out what to do about it until I found this post on the NI forums. Once I disabled the ACPI battery device things got a lot better.

Speedstep also gave me issues, although this was difficult to track down as LatencyMon doesn’t help here. I noticed in the system performance monitor that the reported CPU speed was changing a lot during some audio dropouts so I tried setting the power saving CUP mode to always force the processor to 100%. In the control panel power plan settings, go to “advanced power settings” then to “Processor power managment” and set “minimum processor state” to 100%. I also disabled USB selective suspend.

I also disable all network interfaces. LatencyMon shows that NDIS.sys chews up a lot of resources and when all interfaces are disabled, NDIS is effectively idle. There is also TCPIP.sys and some other related network drivers that seem to do a lot of interrupt handling.

I had some issues with the Windows scheduled tasks like the Windows Assessment Tool running suddenly and causing CPU spikes. Check out this link for details on how do disable Winsat in the scheduled tasks console. Surely Windows search service could cause problems, and a probably a host of others.

Sometimes heavy graphics loads can cause dropouts. However this seems to vary by system. Directx drivers are usually somewhere near the top of the list in LatencyMon, but I only have problems on one of my systems. Minimizing or maximizing, dragging/dropping actions usually trigger these if they are a problem. Both of my systems have similar Intel graphics hardware, so I’m not sure what the determining factor is here.

So to put it in a nutshell, disable ACPI battery and your network adapters and see how far you get. After that set the power plan to 100% CPU all the time and never let anything go to sleep.

I’m able to get 64 samples of latency with NI Guitar Rig, which is my magic number for realtime amp simulation. I can deal with 128 samples if I have to, but anything higher I’d rather just use a pedal or external amp for record monitoring and do latency compensation on playback.