I've owned many pc's during my lifetime, and hopelessly tried to balance using them as gaming pc's and at the same time as daws. I dont really like using a higher audio buffer size than 128, and like so many others I have run into a great amount of problems while walking down this road. These problems have passed on from one audio interface to the next, from one motherboard to the next and from one Windows version to the next (and so forth). I have followed guides and read practically hundreds of forum posts about these type of problems, trying to figure out what the heck hpet, core parking and c-states was all about, to no avail. Sure, I have been able to make music during this time, either by turning up the buffer somewhat, or living with the fact that there could be some occasional hiccups now and then, but I've always had this lingering feeling of something not being quite right.
Well, two years ago I decided to finally get a dedicated daw, and keep all that other unneeded gaming related stuff isolated on its own gaming pc island. I purchased a used mini itx pc with ok stats and a small, practical and square shaped cabinet from Fractal design, and used a voltage controller to keep the cpu's water cooler's pump happily working at a slow rate, keeping that buzzing down to a non-audible level, while making sure that the cpu isnt suitable for frying eggs on by stress testing and monitoring. It was basically completely noiseless, and I could, and can still, hear a pin drop while the daw is turned on, which was a great leap in the right direction. That out of the way I somewhat skeptically purchased the newly released Windows 10 home and crossed my fingers, and I was not negatively surprised, but the problem of the occasional dpc spike remained even if I seemingly turned off all power management features and other stuff I read in all those guides. I soon discovered that the integrated Intel gpu (hd 4600) was an even bigger problem, as maximizing and dragging windows around could create stutters while using low buffers in particularly Cubase, which from version 8 started using a graphics engine that actually takes quite a toll on the gpu processing power. To me it wasnt all that illogical that this caused problems, as the idea of a cpu and gpu sharing the same resources simultaneously seemed like a bad idea. Still, I didnt like the idea of throwing a noisy dedicated gpu into the mix, in an already small cabinet, so I refrained from doing so at the time. I decided that I wanted to keep online access, or at least access to my router, available at all times, so I disabled the wireless card once and for all, and stretched a 10 meter ethernet cable straight through my house (well, first I used a wireless repeater with an ehternet output. Great tip, although max speed can suffer depending on the distance to the router). This helped me get rid of a lot of unnecessary spikes, but I still experienced stutters and spikes at certain points.
However, tired of all these kind of problems I decided to just leave this behind and make the occasional song while keeping building my home studio, trying to avoid having more than one VST window at the time open etc, knowing that I would have to fix this at some point. This point came recently, as I decided to try to put an "old" gtx 770 in my daw to test how this affected things. To my surprise this really helped shape things up, and using Cubase I immediately noticed how much more fluently things ran, and I could even drag around complicated sequencer parts (which takes a non-understandably high toll on gpu processing power) without issue. The 770 was huge in comparison to the rest of the setup though, so it wasnt really ideal, something that fixed itself when I tried plugging in the fan connector on the card while running it powered. I had tried disconnecting it previously to see how hot it ran without the fans, and somehow the connector had slipped out of the socked while mounting it again. Next time I tried booting up the pc the 770 was dead as a dodo. Weird actually, as I have connected and disconnected mobo system fans while powered dozens of times. Wont do that again either. Now, some time passed and I started looking for a replacement while fine tuning other variables like power management, removing and stopping unneeded services from running, downloading gpedit.msc to stop windows update from automatically downloading updates without telling me and a multitude of other small things. My choice landed on a Nvidia GT 1030, as it has a passive cooler and seems to do a fine job compared to its price point, and like earlier mentioned I already have a super powerful gaming rig for that fancy pancy graphical stuff.
Anyhow, gleefully I installed the card, updated the drivers and ran Latency mon to confirm that my latencies was spot on where I wanted them to be and... SUCCESS... NOT. I still had occasional spikes going on, nvlddmkm.sys seemingly being the main culprit with its occasional 2 ms spike. Cursing the digital gods I again started researching potential reasons and plowing through forums. I soon discovered that there had been talk about uncannily high dpc latencies on Pascal chipsets during this time last year, which supposedly was fixed by Nvidia (although several people reported this not being fixed). I tried multiple drivers today and basically started giving up mentally, thinking about how to present the problem to the store I bought the card from, and trying to remember if I kept the original packaging (which I did).
Then, as a last resort I decided to go back to the very first driver that Windows 10 installed with the card, more specifically driver version 382.23, which based on the release notes seems to be specifically dedicated to the release of the GT 1030. And voila! (drum roll) I FINALLY I seem to have NO friggin' dpc latency spikes!
The "funny" part about this is that the "bad" drivers seemingly affected other system drivers as well, like ndis.sys and acpi.sys, which represented smaller but still unnecessarily high +1 ms spikes. Not any more. Here is a horribly lazy mobile camera shot of Latency mon, happily chugging away behind me at this moment (having run coherently 4 hours and 03 minutes, and also one hour flawlessly before this run):
Like stated, this is with an active ethernet connection and also roughly 10 misc usb devices relating to audio production connected. Anyhow, I dont know if this was worth all the time spent writing up this summary, as I probably will be woken up in two hours by a merciless girlfriend and a baby, but this is in fact a really big thing for me, and I felt the need to share. So, why not here, where at least some of you (non-Mac users) can relate?
Oh, and feel free to ask if there is anything I can do to assist with trying to figure out this mess called deferred procedure calls. Just run Latency mon first and see what it blames as the culprit for all of your misfortunes. Most likely it will be a network issue, in particular if you run on wireless, a power management related issue (acpi.sys) or a graphics related process. Do remember to turn off "sleep" for the monitor if you are running prolonged tests, as this will most definitely cause a false positive in regards to the display driver causing a high spike (probably a bit above 2 ms). I turned it off completely and permanently just to make sure, and merely use a black screensaver to misguidedly feel better about wasting energy. Anyways, I hope that this may contribute to inspire some of you to not give up your quest for the holy grailatency.
Regards,
Chris
PS: Here is the better part of my home studio:
PS: 0,2 ms is no problem with realtime audio.