New
#1
Solution to Audio glitches/How to Ensure General Real-time Performance
Dear Ten Forums,
If you've been struggling with audio glitches on a Windows 10 system with an adequately powerful laptop (8Gb of ram, processor N5000 is fast enough), I may have the solution. I take it you've tried the pretty useless audiotroubleshooter - deleting and re-installing drivers, turning off enhancements, going to the manufacturer's website to download the correct drivers to no avail. I suggest doing a deep virus scan first with say Windows Defender and something like Malwarebytes (google it),
1. First identify the problem
(You can skip this and go ahead to the solution, if you want.)
If you tried all that, google "LatencyMon" and install it. This brilliant tool will let you see what drivers and interrupts are causing sound problems on your system. Mostly likely you'll find ACPI.sys (to do with battery monitoring) or the mysterious "wdf01000.sys". I've seen ACPI.sys take up to 0.2 seconds supposedly doing an interrupt routine (more an "imposition" routine).
Microsoft or the manufacturers don't look like they'll get around to fixing these problems, hell, they'll fix it one Windows update and then in two weeks "unfix" it, as happened to me when I did an update for Windows 10 early 2021.
If you observe this, I suggest trying the simple fixes below.
2. This solution may be applicable to Windows 10 and Windows 7, even other versions.
Some software is broken so my solution is to isolate it onto a particular core.
ACPI.sys and wdf01000.sys seem to either run on all cores or default to core 0 or core 0/1 - as do the other processes.
You can try typing tasklist /SVC into a cmd prompt and scroll through the list to find the svchost.exe processes, which are a kind of container for all the sys files running. You'll see the process ID number and then a list of the sys files running in that process. Some of the names maybe slightly different, i.e. ACPI.sys might just be called "Power".
You can either set the affinity (more on that later) for the services audiosrv and audioendpointbuilder to specific cores or set the affinity for ACPI.sys and wdf01000.sys, I prefer the former.
Start up taskmanager (taskmgr.exe) and you'll probably need to be Administrator and go to the services tab:
There look for Windows Audio and Windows Audio Endpoint Builder. Right click on one, then the other to "Go to detail". Under Windows 7 that may be called "Go to process".
You'll be taken to the running process tabs
Where you right click on the process that has been highlighted and chose "Set affinity". There choose the other cores as invariably microsoft puts interrupts on core 0 or 1 (or all cores, we'll come back to this point shortly), thus giving the audio services a fair crack of the whip when it comes to running on time.
Now as mentioned you can do the converse and limit ACPI.sys and other errant drivers (or maybe I should say, not well coded drivers) to a particular core but you will need to use tasklist /SVC and sift through the data it provides:
There you can see that I have probably located the instance of ACPI.sys running and then I can take note of the process ID and do the same thing in task manager, set the affinity and limit it to a particular core.
This may all be fine and dandy but you say, each time I reboot, I have to go through this rigmarole. Well it's not that difficult to do, I tend to leave my computer booted for weeks and just sleep it or hibernate it. If you want a permanent fix, there are alternatives to task manager which can remember your settings for processes, just google it.
By this method of just setting the affinity of the audio services to their own cores, I have seen a drastic improvement in sound quality. I could make it even better by limiting the other services to core 0 (they seem to be default to run on all cores) but that is a more complicated variation of what is above - you have to identify the likely process containing the sys file running from the screenload that tasklist /SVC gives you.
Hope that helps.
- - - Updated - - -
Method has general applicability to errant (badly coded) drivers -
Isolate them onto one core so that they don't affect the real time performance of the rest of your system with random glitches. If they can potentially run on any core, they might clash with your process, should it be scheduled for the same core. By deterministically setting which core it runs on and putting your other code on to the other cores, there is little chance that a poorly written interrupt routine can de-schedule your code.
Last edited by RemC; 29 Apr 2021 at 19:27. Reason: General applicability of the solution to ensure real-time performance