What's new

[SOLVED] Win10 audio stutter issue

xGodot

Member
Joined
Dec 25, 2018
Messages
6
Hello there, I'm been having an audio problem with Win10 on a recently purchased Dell laptop.
I started the system for the first time three weeks ago, and been having this problem since then.

Problem details
When I listen to music or play games the audio stutters/does a "glitch-like" sound for a split second. The video or videogame does not freeze or stutter.
I realized this some days ago but it always happens every 15 minutes. I tested this while listening to Youtube for 3 hours and it always happened with that frequency.
From this I realized it may be a process/application related problem but I haven't been able to find the culprit.
Things I tried to do after searching the net (all without effect)
-Disinstalling Realtek Audio Drivers, currently using windows native audio drivers (and an external DAC when using headphones)
-Disabling Wireless Intel Drivers since I always use ethernet and read that it may be the culprit (it isn't)
-Confirmed that the BIOS version is the latest one
-Confirmed that the drivers from Dell are up to date
Other Spec (rest is down below in the log and speccy's link)
-Driver verifier is enabled
-Currently using Windows Defender as security software
-Using standard Windows Defender firewall and antimalware
-Not using any Disk image tools
-
Not overclocking or underclocking

I actually ended up in this forum after downloading and trying to run Latencymon. The value "Highest measured interrupt to process latency (µs)" goes from 2.6k of value to something between 20k-45k after the audio stutters. I couldn't find the culprit anyway, after trying to disable acpi.sys because it (almost) always had the highest values for DPC/ISR. Once I confirmed that it did nothing I enabled it again. Below I'm going to paste the latest Latencymon report log, registered until the stutter happened and took almost together with the trace (link below).
Following the forum guide, here are the other links:
Trace (run until after the stutter occcurred), msinfo32 and dxdiag.exe zip file download: here
Speccy: here

Thanks in advance for any help, I really hope I can defeat this problem once and for all!

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:04:46 (h:mm:ss) on all processors.




_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: DESKTOP-PDJOOFM
OS version: Windows 10 , 10.0, build: 17134 (x64)
Hardware: G7 7588, Dell Inc., 0FDMYT
CPU: GenuineIntel Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
Logical processors: 12
Processor groups: 1
RAM: 16178 MB total




_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 2208 MHz


Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.




_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.


Highest measured interrupt to process latency (µs): 41990,087406
Average measured interrupt to process latency (µs): 4,334724


Highest measured interrupt to DPC latency (µs): 3289,048054
Average measured interrupt to DPC latency (µs): 1,143264




_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.


Highest ISR routine execution time (µs): 359,461051
Driver with highest ISR routine execution time: ndis.sys - NDIS (Network Driver Interface Specification), Microsoft Corporation


Highest reported total ISR routine time (%): 0,005299
Driver with highest ISR total time: ACPI.sys - Driver ACPI per NT, Microsoft Corporation


Total time spent in ISRs (%) 0,008294


ISR count (execution time <250 µs): 34220
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 2
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0




_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.


Highest DPC routine execution time (µs): 2760,596014
Driver with highest DPC routine execution time: ACPI.sys - Driver ACPI per NT, Microsoft Corporation


Highest reported total DPC routine time (%): 0,022009
Driver with highest DPC total execution time: Wdf01000.sys - Runtime framework driver modalità kernel, Microsoft Corporation


Total time spent in DPCs (%) 0,062329


DPC count (execution time <250 µs): 651154
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 422
DPC count (execution time 1000-1999 µs): 49
DPC count (execution time 2000-3999 µs): 5
DPC count (execution time >=4000 µs): 0




_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.


NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.


Process with highest pagefault count: msmpeng.exe


Total number of hard pagefaults 19
Hard pagefault count of hardest hit process: 14
Number of processes hit: 4




_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 10,892731
CPU 0 ISR highest execution time (µs): 359,461051
CPU 0 ISR total execution time (s): 0,284728
CPU 0 ISR count: 34222
CPU 0 DPC highest execution time (µs): 2760,596014
CPU 0 DPC total execution time (s): 2,118549
CPU 0 DPC count: 649591
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 25,570906
CPU 1 ISR highest execution time (µs): 0,0
CPU 1 ISR total execution time (s): 0,0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 10,725543
CPU 1 DPC total execution time (s): 0,000051
CPU 1 DPC count: 11
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 13,321109
CPU 2 ISR highest execution time (µs): 0,0
CPU 2 ISR total execution time (s): 0,0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 82,653080
CPU 2 DPC total execution time (s): 0,000207
CPU 2 DPC count: 27
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 19,230586
CPU 3 ISR highest execution time (µs): 0,0
CPU 3 ISR total execution time (s): 0,0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 105,271739
CPU 3 DPC total execution time (s): 0,000427
CPU 3 DPC count: 37
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 12,550763
CPU 4 ISR highest execution time (µs): 0,0
CPU 4 ISR total execution time (s): 0,0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 256,848732
CPU 4 DPC total execution time (s): 0,002172
CPU 4 DPC count: 368
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 13,487699
CPU 5 ISR highest execution time (µs): 0,0
CPU 5 ISR total execution time (s): 0,0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 144,774457
CPU 5 DPC total execution time (s): 0,001531
CPU 5 DPC count: 117
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 11,500197
CPU 6 ISR highest execution time (µs): 0,0
CPU 6 ISR total execution time (s): 0,0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 202,134964
CPU 6 DPC total execution time (s): 0,004443
CPU 6 DPC count: 407
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 11,811212
CPU 7 ISR highest execution time (µs): 0,0
CPU 7 ISR total execution time (s): 0,0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 198,961957
CPU 7 DPC total execution time (s): 0,000743
CPU 7 DPC count: 51
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s): 11,275687
CPU 8 ISR highest execution time (µs): 0,0
CPU 8 ISR total execution time (s): 0,0
CPU 8 ISR count: 0
CPU 8 DPC highest execution time (µs): 252,135870
CPU 8 DPC total execution time (s): 0,005989
CPU 8 DPC count: 472
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s): 11,839309
CPU 9 ISR highest execution time (µs): 0,0
CPU 9 ISR total execution time (s): 0,0
CPU 9 ISR count: 0
CPU 9 DPC highest execution time (µs): 146,798007
CPU 9 DPC total execution time (s): 0,000228
CPU 9 DPC count: 18
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s): 9,306371
CPU 10 ISR highest execution time (µs): 0,0
CPU 10 ISR total execution time (s): 0,0
CPU 10 ISR count: 0
CPU 10 DPC highest execution time (µs): 137,051630
CPU 10 DPC total execution time (s): 0,005094
CPU 10 DPC count: 521
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s): 9,377155
CPU 11 ISR highest execution time (µs): 0,0
CPU 11 ISR total execution time (s): 0,0
CPU 11 ISR count: 0
CPU 11 DPC highest execution time (µs): 127,619565
CPU 11 DPC total execution time (s): 0,000160
CPU 11 DPC count: 10
_________________________________________________________________________________________________________


 

cwsink

Sysnative Staff, BSOD Kernel Dump Expert
Joined
Apr 3, 2017
Messages
275
Hi xGodot,

I'd suggest disabling Driver Verifier for now as it's not likely to detect audio glitch problems and might confuse things in traces. The trace isn't showing anything obvious from what I can tell and seems to be missing some needed data - which I've seen in other traces. I'm not sure if something has changed but many of the traces captured lately seem to be missing the same data so perhaps the instructions need to be edited or updated.

My suggestion would be to basically do the same thing but use the command:
Code:
xperf -on PROC_THREAD+LOADER+PROFILE+INTERRUPT+DPC+DISPATCHER+CSWITCH -stackwalk Profile+CSwitch+ReadyThread -BufferSize 1024 -MinBuffers 256 -MaxBuffers 256 -MaxFile 256 -FileMode Circular
to start the trace. While it's running use the computer as you normally do until you experience an audio glitch and then run the command:
Code:
xperf -stop -d "%userprofile%\Desktop\cpu.etl"
That should generate a trace called cpu.etl on your Desktop and it should contain everything the CPU was doing along with context metadata. It's a circular buffer trace so you can run it as long as it takes for an audio glitch to happen; then you'll have 30 to 40 seconds to run the stop command before the portion of the trace containing the audio glitch data is overwritten. The file will likely be around 260MB so you may need to make it available via a cloud drive or file sharing service if it's too big to attach after compression.
 

xGodot

Member
Joined
Dec 25, 2018
Messages
6
Hi cwsink, thanks for your reply.

I did as you asked, disabled driver verifier and starting to took a trace using the command above.
Trace: here

Unfortunately is 4MB like the last one I uploaded so it might be missing those informations you're speaking of...
I took the trace up until the stutter happened (again, exactly 15 minutes) and stopped it 5 seconds after.
 

cwsink

Sysnative Staff, BSOD Kernel Dump Expert
Joined
Apr 3, 2017
Messages
275
Hmmm... the latest trace doesn't seem to have the data, either, as you said. I do see that you have a Killer Networking Ethernet adapater, though. In the past the software which often gets installed by OEM installers (called Killer Performance Suite) has caused problems for people. I don't recall anyone mentioning the symptoms you described but if you do have it installed I'd suggest checking your non-paged pool memory in Task Manager to see if it's growing very large. Anything over 600MB would be abnormal for non-paged pool and the KPS software often ends up using many gigabytes of physical memory.
 

xGodot

Member
Joined
Dec 25, 2018
Messages
6
I actually disinstalled every program that came with the Killer ethernet drivers. Killer Control Center gave me problems and I deleted that and Performance Suite together.
Later I did a clean install of the drivers and only have them on the laptop as of now. The problems were internet-speed related.

I tried to run the command again earlier but got this error message: xperf: error: NT Kernel Logger: Cannot create a file when that file already exists. (0xb7)
I don't have any cpu.etl on the desktop now.. Is this somehow related to the reason I can't create a trace with that necessary data? I didn't get this error yesterday when I entered the command.
I also tried to look on google for info as to why I can't get a normal sized trace but strangely I can't find anything...

 

cwsink

Sysnative Staff, BSOD Kernel Dump Expert
Joined
Apr 3, 2017
Messages
275
A temporary file is created named "kernel.etl" during an xperf trace. On my system it gets overwritten automatically when I run the commands I listed in my previous reply from an elevated command prompt. Perhaps there's a permissions issue preventing that file from being overwritten from the command prompt you're using. You are running the commands from an command prompt that has been granted administrator permissions?

I'd check to see if "kernel.etl" exists at the root of the C: drive as well as the root of any other drive from which you've run the commands and delete them, if possible. I've not been able to recreate the problem on my computer so I'm not sure that's the issue.
 

xGodot

Member
Joined
Dec 25, 2018
Messages
6
I might have found the culprit. After three weeks of uninstalling and installing drivers, doing some obscure (for my computer level at least) stuff and looking at all possible solutions... today I found a thread in the Dell forums regarding an update about Dell Support Assist. It was actually a 2015 thread so I thought it wouldn't interested my problem that much... until I read that as soon as the users deleted the DSA program they got rid of the stutter and could move on. I'm not 100% sure it was DSA but after uninstalling it and a few other Dell programs just in case (all except Dell update) I noticed that the stutter was gone. Latencymon didn't display the usual 20k-45k value I mentioned before in the thread, after about 50 minutes of listening.

I don't have much time these days but I will of course continue to monitor the situation so I can be 100% sure that was the cause.
I'll post again in this thread in the new year to confirm it.

Also regarding the command prompt error, yeah I run it as admin. The kernel.etl was in the C:drive root but even after deleting it the error for the trace command came out.
I tried spamming it and surprisingly worked after a few tries, even though the trace file I get is always 4mb.
 

cwsink

Sysnative Staff, BSOD Kernel Dump Expert
Joined
Apr 3, 2017
Messages
275
Thank you for the update and good job hunting that nugget down - it sounds promising. Please do let us know whether or not the problem is resolved after what you'd consider a reasonable amount of time testing.

As far as the xperf error, the only other thing that came to mind (which seems to be confirmed in this post) is another program starting a kernel trace since which is then preventing xperf from starting a trace. There are many tools which could be doing so as mentioned in the link. It's possible LatencyMon is using ETW tracing as well - though I don't know for sure.
 

xGodot

Member
Joined
Dec 25, 2018
Messages
6
Sorry for the late reply.
I tested the audio for like 10 hours and no stutter detected :smile9:
I guess I'll reinstall back the Realtek drivers too, since they were not the cause.
Thanks for the advices cwsink!
 

cwsink

Sysnative Staff, BSOD Kernel Dump Expert
Joined
Apr 3, 2017
Messages
275
Thank you for letting us know. That could be useful information for quite a few people, I would imagine. If you would, please mark your post as solved which could make it easier for people to find if they include "solved" in their searches.
 

xGodot

Member
Joined
Dec 25, 2018
Messages
6
Sorry for being late again, modified the thread as solved.
I re-installed the realtek drivers as well and the stutter hasn't come back.
 
Top