Windows 11 Audio glitches - multiple interfaces

[TangoGrowler]

Hello. First post on here, so please be gentle.

Windows audio recently became unusable for me - across multiple interfaces/hardware, so it's unlikely to be a driver issue

I'm running Windows 11 Pro 24H2 Build 26100.2894. The issues PROBABLY started around the same time that 24H2 appeared as an option, but I can't be sure, to be honest. After it started happening, one of the first things I tried was Windows update, but that just made things worse in that it took out all of my regularly taken System Restore Points - thank you Microsoft. I have since read about audio issues with 24H2 but they seem different to this issue.

It started happening suddenly after several months of glitch free audio. Strangely, it can also be fine sometimes when it boots up, then the next time it's unusable again.

It is much worse on my primary USB-C audio device, but still noticable via HDMI audio. I've attached a recording of the issue.

I have tried updating my primary Audio interface (Steinberg UR44-C) drivers and even an in-place re-install of windows (keeping apps and settings). I have tried culling various start-up apps & services. Also, restarting the Windows Audio services.

Since this is a PC dedicated to music making, this is so so annoying for me. I would love to not have to spend a couple of days reinstalling from scratch

Anyone got any ideas for troubleshooting or fixed an issue like this previously???

Thanks in advance

 

[ChatGPT]

Welcome to the forum, TangoGrowler! Thanks for providing all the relevant details about your issue, and no worries—I promise to be gentle.
You've been very thorough with your troubleshooting, which is excellent! Based on your description, here's an analysis and steps you can take to hone in on the cause of your audio glitches:

---

Diagnostic Questions​

Before diving into potential fixes, one key thing jumps out: the intermittent nature of the issue. This suggests it's not just a driver or hardware problem but could relate to software conflicts, system-level corruption, or how audio services are handled across 24H2.

• Does this issue persist if you disable all non-essential startup items and services using MSConfig (or via Task Manager)? If culling startup apps improved the situation even slightly, a software/service conflict may be behind the issue.
• Are you using any specific background apps for music creation (DAWs like Cubase/FL Studio), audio routing software, or plugins (ASIO drivers, etc.) during playback? These can also be sensitive when updates are rolled out to any Windows subsystem like audio.
• Does your issue worsen with certain higher CPU or memory usage conditions? Resource contention can exacerbate latency and audio glitches.
• Have you tried bypassing USB-C for your Steinberg interface? USB-C compatibility quirks occasionally surface in latency-heavy workloads.

---

Recommendations:​

1. Audio Latency Diagnostics​

Real-time sensitive audio work is prone to issues introduced by background interruptions. Here’s how to test this:

• Download LatencyMon: https://www.resplendence.com/latencymon
• Run it while reproducing your issue to see if high latency drivers or kernel modules are interfering with audio streams.
• If it flags specific drivers or processes (e.g., "DirectX Kernel" or "WDF Filter"), we can dig deeper there.

2. Revert or Fine-Tune Windows Audio Enhancements​

• Open Sound Settings (right-click the sound icon in the taskbar > "Sound settings").
• Locate your current playback devices (Steinberg or HDMI speakers) > Device Properties > Additional Device Properties:
• Disable "Audio Enhancements" in the "Advanced" tab.
• Confirm that sample rates/bit depths align between hardware and software. For high-end audio work, set both the input/output sample rate to 48kHz or precise matching specs of your Steinberg interface.

Sticking with uniform buffer sizes in both Windows and Cubase (or other creative software) can also mitigate these drops.

3. Test via Alternate Audio API (ASIO, WASAPI)​

For music production, you likely default to an ASIO driver. However, it might be interesting to verify how WASAPI behaves:

• Use the Windows default audio interface (Realtek or HDMI) and configure your DAW for WASAPI Exclusive Mode (if supported). This helps isolate driver faults in ASIO vs. the core OS.

4. Check the Power Management Profile for USB​

Since USB-C is glitchier than HDMI, this may tie into USB power settings:

• Open Device Manager, locate USB Root Hubs, and disable "Allow the computer to turn off this device to save power" under Power Management.
• Similarly, create a High Performance Power Plan in Windows 11 (or modify your current one).
• Search Edit Power Plan > Change Advanced Power Settings.
• Expand USB settings > USB selective suspend setting and set it to Disabled.

5. Rollback or Repair Audio Drivers, Temporarily Disconnect Steinberg​

• Although you've tried reinstalling drivers, check Device Manager > View > Show hidden devices to remove ghosted legacy audio drivers completely.
• If Windows recently applied optional updates during the 24H2 rollout, test older drivers obtained directly from Steinberg's support page: https://www.steinberg.net/en/support.
• Try playing audio using HDMI only during a session, fully unplugging the Steinberg box to monitor performance.

6. Disable SysMain (Superfetch) and Indexing Services​

Services like SysMain have been known to cause unpredictable disruptions in audio pipelines, particularly in newer builds:

• Search "services.msc" > Locate "SysMain" > Disable and Stop.
• Similarly disable unnecessary indexing under Indexing Options in the Control Panel.

7. Last-Resort Fix - Outdated Firmware?​

Check for firmware updates for your Steinberg UR44-C hardware. If none are available or audio distortions still persist WITHOUT windows/third-party drivers loaded (using generic "plug-and-play audio" from the OS), this is rare, but occasionally firmware itself is at fault.

---

Next Steps​

Could you also clarify the following:

• On which devices (headphones/speakers) the glitches are easiest to reproduce?
• Share your observations from the attached recordings (let me know if I should analyze your audio .zip).

If none of the suggestions above yield positive results, it may require rolling back from 24H2. Before doing this, provide me updates or results from using LatencyMon—this is likely our best way to pinpoint systemic delays.
Let me know how you'd like to proceed!

 

[TangoGrowler]

Welcome to the forum, TangoGrowler! Thanks for providing all the relevant details about your issue, and no worries—I promise to be gentle.
You've been very thorough with your troubleshooting, which is excellent! Based on your description, here's an analysis and steps you can take to hone in on the cause of your audio glitches:

---

Diagnostic Questions​

Before diving into potential fixes, one key thing jumps out: the intermittent nature of the issue. This suggests it's not just a driver or hardware problem but could relate to software conflicts, system-level corruption, or how audio services are handled across 24H2.

1. Does this issue persist if you disable all non-essential startup items and services using MSConfig (or via Task Manager)? If culling startup apps improved the situation even slightly, a software/service conflict may be behind the issue.
2. Are you using any specific background apps for music creation (DAWs like Cubase/FL Studio), audio routing software, or plugins (ASIO drivers, etc.) during playback? These can also be sensitive when updates are rolled out to any Windows subsystem like audio.
3. Does your issue worsen with certain higher CPU or memory usage conditions? Resource contention can exacerbate latency and audio glitches.
4. Have you tried bypassing USB-C for your Steinberg interface? USB-C compatibility quirks occasionally surface in latency-heavy workloads.

---

Recommendations:​

1. Audio Latency Diagnostics​

Real-time sensitive audio work is prone to issues introduced by background interruptions. Here’s how to test this:

• Download LatencyMon: Resplendence Software - LatencyMon: suitability checker for real-time audio and other tasks
• Run it while reproducing your issue to see if high latency drivers or kernel modules are interfering with audio streams.
  • If it flags specific drivers or processes (e.g., "DirectX Kernel" or "WDF Filter"), we can dig deeper there.

2. Revert or Fine-Tune Windows Audio Enhancements​

• Open Sound Settings (right-click the sound icon in the taskbar > "Sound settings").
• Locate your current playback devices (Steinberg or HDMI speakers) > Device Properties > Additional Device Properties:
  • Disable "Audio Enhancements" in the "Advanced" tab.
  • Confirm that sample rates/bit depths align between hardware and software. For high-end audio work, set both the input/output sample rate to 48kHz or precise matching specs of your Steinberg interface.
  Sticking with uniform buffer sizes in both Windows and Cubase (or other creative software) can also mitigate these drops.

3. Test via Alternate Audio API (ASIO, WASAPI)​

For music production, you likely default to an ASIO driver. However, it might be interesting to verify how WASAPI behaves:

• Use the Windows default audio interface (Realtek or HDMI) and configure your DAW for WASAPI Exclusive Mode (if supported). This helps isolate driver faults in ASIO vs. the core OS.

4. Check the Power Management Profile for USB​

Since USB-C is glitchier than HDMI, this may tie into USB power settings:

• Open Device Manager, locate USB Root Hubs, and disable "Allow the computer to turn off this device to save power" under Power Management.
• Similarly, create a High Performance Power Planin Windows 11 (or modify your current one).
  1. Search Edit Power Plan > Change Advanced Power Settings.
  2. Expand USB settings > USB selective suspend setting and set it to Disabled.

5. Rollback or Repair Audio Drivers, Temporarily Disconnect Steinberg​

• Although you've tried reinstalling drivers, check Device Manager > View > Show hidden devices to remove ghosted legacy audio drivers completely.
• If Windows recently applied optional updates during the 24H2 rollout, test older drivers obtained directly from Steinberg's support page: Steinberg Support.
• Try playing audio using HDMI only during a session, fully unplugging the Steinberg box to monitor performance.

6. Disable SysMain (Superfetch) and Indexing Services​

Services like SysMain have been known to cause unpredictable disruptions in audio pipelines, particularly in newer builds:

• Search "services.msc" > Locate "SysMain" > Disable and Stop.
• Similarly disable unnecessary indexing under Indexing Options in the Control Panel.

7. Last-Resort Fix - Outdated Firmware?​

Check for firmware updates for your Steinberg UR44-C hardware. If none are available or audio distortions still persist WITHOUT windows/third-party drivers loaded (using generic "plug-and-play audio" from the OS), this is rare, but occasionally firmware itself is at fault.

---

Next Steps​

Could you also clarify the following:

1. On which devices (headphones/speakers) the glitches are easiest to reproduce?
2. Share your observations from the attached recordings (let me know if I should analyze your audio .zip).

If none of the suggestions above yield positive results, it may require rolling back from 24H2. Before doing this, provide me updates or results from using LatencyMon—this is likely our best way to pinpoint systemic delays.
Let me know how you'd like to proceed!

Here is the "Stats" output from LatencyMon, measured while using the Steinberg UR44-C interface for audio playback:

_________________________________________________________________________________________________________
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:00:13 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: xxx
OS version: Windows 11, 10.0, version 2009, build: 26100 (x64)
Hardware: System Product Name, ASUS
BIOS: 2002
CPU: GenuineIntel 11th Gen Intel(R) Core(TM) i9-11900K @ 3.50GHz
Logical processors: 16
Processor groups: 1
Processor group size: 16
RAM: 32637 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed (WMI): 3504 MHz
Reported CPU speed (registry): 3504 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): 174.20
Average measured interrupt to process latency (µs): 7.980857

Highest measured interrupt to DPC latency (µs): 131.80
Average measured interrupt to DPC latency (µs): 3.307958


_________________________________________________________________________________________________________
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): 156.996005
Driver with highest ISR routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total ISR routine time (%): 0.044603
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in ISRs (%) 0.079261

ISR count (execution time <250 µs): 159434
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µ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): 103819.629566
Driver with highest DPC routine execution time: storport.sys - Microsoft Storage Port Driver, Microsoft Corporation

Highest reported total DPC routine time (%): 0.223959
Driver with highest DPC total execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in DPCs (%) 0.333013

DPC count (execution time <250 µs): 171971
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 17
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 1


_________________________________________________________________________________________________________
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: avp.exe

Total number of hard pagefaults 8
Hard pagefault count of hardest hit process: 4
Number of processes hit: 3


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 0.947744
CPU 0 ISR highest execution time (µs): 156.996005
CPU 0 ISR total execution time (s): 0.166043
CPU 0 ISR count: 159434
CPU 0 DPC highest execution time (µs): 381.364726
CPU 0 DPC total execution time (s): 0.585012
CPU 0 DPC count: 169490
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 0.260754
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): 12.104452
CPU 1 DPC total execution time (s): 0.000110
CPU 1 DPC count: 44
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 0.208442
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): 64.830479
CPU 2 DPC total execution time (s): 0.000453
CPU 2 DPC count: 394
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 0.239474
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): 12.639840
CPU 3 DPC total execution time (s): 0.000097
CPU 3 DPC count: 24
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 0.040703
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): 36.861872
CPU 4 DPC total execution time (s): 0.000065
CPU 4 DPC count: 12
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 0.040536
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): 32.052511
CPU 5 DPC total execution time (s): 0.000068
CPU 5 DPC count: 8
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 0.037143
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): 72.182648
CPU 6 DPC total execution time (s): 0.000091
CPU 6 DPC count: 2
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 0.033708
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): 0.0
CPU 7 DPC total execution time (s): 0.0
CPU 7 DPC count: 0
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s): 0.231841
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): 11.809361
CPU 8 DPC total execution time (s): 0.000020
CPU 8 DPC count: 8
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s): 0.215333
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): 14.718037
CPU 9 DPC total execution time (s): 0.000143
CPU 9 DPC count: 35
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s): 0.216702
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): 55.670662
CPU 10 DPC total execution time (s): 0.000358
CPU 10 DPC count: 79
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s): 1.673905
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): 103819.629566
CPU 11 DPC total execution time (s): 0.110854
CPU 11 DPC count: 1804
_________________________________________________________________________________________________________
CPU 12 Interrupt cycle time (s): 0.17970
CPU 12 ISR highest execution time (µs): 0.0
CPU 12 ISR total execution time (s): 0.0
CPU 12 ISR count: 0
CPU 12 DPC highest execution time (µs): 8.002854
CPU 12 DPC total execution time (s): 0.000016
CPU 12 DPC count: 3
_________________________________________________________________________________________________________
CPU 13 Interrupt cycle time (s): 0.258811
CPU 13 ISR highest execution time (µs): 0.0
CPU 13 ISR total execution time (s): 0.0
CPU 13 ISR count: 0
CPU 13 DPC highest execution time (µs): 30.869863
CPU 13 DPC total execution time (s): 0.000150
CPU 13 DPC count: 50
_________________________________________________________________________________________________________
CPU 14 Interrupt cycle time (s): 0.194766
CPU 14 ISR highest execution time (µs): 0.0
CPU 14 ISR total execution time (s): 0.0
CPU 14 ISR count: 0
CPU 14 DPC highest execution time (µs): 11.339612
CPU 14 DPC total execution time (s): 0.000043
CPU 14 DPC count: 15
_________________________________________________________________________________________________________
CPU 15 Interrupt cycle time (s): 0.268166
CPU 15 ISR highest execution time (µs): 0.0
CPU 15 ISR total execution time (s): 0.0
CPU 15 ISR count: 0
CPU 15 DPC highest execution time (µs): 41.364726
CPU 15 DPC total execution time (s): 0.000146
CPU 15 DPC count: 21
_________________________________________________________________________________________________________

 

[ChatGPT]

Thank you for sharing the detailed LatencyMon report, TangoGrowler! Here's my analysis based on the statistics you've posted, and trust me—this breakdown might sting less than the glitches you're experiencing. Let's fix it!

---

Key Findings from LatencyMon:​

• Severe DPC Latency Issues
• The storport.sys driver (Microsoft Storage Port Driver) caused a 103,819 µs DPC routine execution time, which is staggeringly high. This driver relates to storage interaction, meaning it could potentially disrupt audio streams, especially if disk activity interferes with the audio pipeline.
• Additional culprits include dxgkrnl.sys (DirectX Graphics Kernel) with ISR issues and wdf01000.sys (Kernel Mode Driver Framework Runtime). These drivers hint at deeper conflicts in graphics/audio routing and device management.
• Power Management and CPU Throttling
• LatencyMon suggests disabling Intel Speed Step or CPU throttling, as these can cause real-time interruptions, especially in E-cores/P-cores of modern Intel CPUs (your i9-11900K seems particularly susceptible).
• Moderate Hard Pagefaults
• Specific processes like avp.exe (likely AV-Kaspersky Antivirus) triggered 4 hard pagefaults, which may impact audio playback timing but are a secondary concern compared to high DPC latencies.

---

Step-by-Step Fixes:​

1. Address storport.sys - Microsoft Storage Port Driver​

• Since storport.sys is linked to storage drivers and can interfere with real-time operations:
• Update SATA/Storage (AHCI, NVMe) Drivers:
• Visit your motherboard vendor's page (ASUS in your case) to locate chipset drivers, particularly any NVMe controller updates or Intel Rapid Storage Technology (IRST).
• Alternatively, download the latest chipset drivers from Intel: https://www.intel.com/content/www/us/en/support/detect.html.
• Disable unused SATA ports in the BIOS if you have disconnected drives or no hardware connected.
• Windows storage services tuning:
• Open Services.msc, locate SysMain, and disable it (as previously recommended). SysMain (formerly Superfetch) can exacerbate storage-related latency.
• If you’re on an NVMe SSD, ensure the correct power state (e.g., ASPM settings) and drive firmware are installed using Samsung Magician or an equivalent tool for diagnostics.

---

2. Handle dxgkrnl.sys + GPU Interrupt Issues​

• The DirectX Graphics Kernel misbehaving could indicate GPU driver or display settings are conflicting with the system.
• Update GPU Drivers:
• Use the clean installation option available during NVIDIA/AMD driver installation to wipe remnants of old drivers.
• Disable Hardware-Accelerated GPU Scheduling (HAGS):
• Search "Graphics Settings" in the start menu.
• If enabled, toggle HAGS off to reduce DPC contention.

---

3. USB-C Interface (wdf01000.sys + Power Management)​

• The Kernel Mode Driver Framework Runtime (wdf01000.sys) contributed to high ISR and DPC activity, which correlates directly with USB hardware interrupts (your Steinberg UR44-C being reliant on USB-C).
• Disable USB Selective Suspend:
• Open Power Options > Advanced Settings > USB Settings > Disable Selective Suspend.
• Adjust BIOS Settings for USB and PCIe Power Management:
• Enter the BIOS, look for power-saving settings like ASPM or USB power modes, and disable them.
• Ensure USB-C compatibility is set to full bandwidth mode, if such an option exists.
• Update Steinberg and UR44-C Firmware/Drivers:
• You’ve already tried driver updates, but double-check on their https://www.steinberg.net/en/support for the latest firmware. Some USB audio devices require firmware alignment with newer Windows builds.

---

4. Disable Intel Speed Step / EIST in BIOS​

Modern Intel CPUs dynamically throttle clock speeds for power efficiency, which can wreak havoc with low-latency audio functions.

• Disable Intel SpeedStep (or Enhanced Intel SpeedStep, EIST) and C-States in your BIOS.
• Set the CPU frequency to a locked value (sync all cores at base clock).
  BIOS Steps:
• Reboot and hit DEL/F2 to enter BIOS.
• Navigate to the CPU Settings or Overclocking Menu.
• Find Intel SpeedStep or energy-saving features like C1/C6 States, and disable them.

---

5. Examine Antivirus/Background Interference (avp.exe)​

• The hard pagefaults involving avp.exe suggest Kaspersky is occasionally interfering with audio threads.
• Temporarily disable Kaspersky or run your system in Safe Mode with Networking to see if the problem abates during audio playback.
• Disable Real-Time Scanning for large media libraries.

---

6. Optimize Audio Performance Further​

• Switch to a High Performance Power Plan but create a custom one tailored for audio production.
• Set Minimum CPU State to 100%.
• Disable timeout/power-saving features for USB and PCIe devices.
• Revisit your audio buffer size in Steinberg’s control panel (ASIO). A larger buffer size can temporarily stabilize audio streams while pinpointing the underlying issue.

---

7. Monitor and Test​

• After trying any of the above, revisit LatencyMon to check if storport.sys, dxgkrnl.sys, or wdf01000.sys have been tamed.
• Reproduce the original glitch across your HDMI audio and Steinberg interface and gather fresh stats for analysis.

---

If All Else Fails:​

If the process of addressing each driver doesn’t resolve the glitches entirely, testing a rollback from 24H2 via Windows Recovery Options or a clean reinstall may circumvent recent regressions. However, this is a last resort after attempting all above suggestions.
Let me know which remedies worked—or if additional diagnostics (or reviewing provided recordings) is needed!

 

[TangoGrowler]

Thank you for sharing the detailed LatencyMon report, TangoGrowler! Here's my analysis based on the statistics you've posted, and trust me—this breakdown might sting less than the glitches you're experiencing. Let's fix it!

---

Key Findings from LatencyMon:​

1. Severe DPC Latency Issues
   • The storport.sys driver (Microsoft Storage Port Driver) caused a 103,819 µs DPC routine execution time, which is staggeringly high. This driver relates to storage interaction, meaning it could potentially disrupt audio streams, especially if disk activity interferes with the audio pipeline.
   • Additional culprits include dxgkrnl.sys (DirectX Graphics Kernel) with ISR issues and wdf01000.sys (Kernel Mode Driver Framework Runtime). These drivers hint at deeper conflicts in graphics/audio routing and device management.
2. Power Management and CPU Throttling
   • LatencyMon suggests disabling Intel Speed Step or CPU throttling, as these can cause real-time interruptions, especially in E-cores/P-cores of modern Intel CPUs (your i9-11900K seems particularly susceptible).
3. Moderate Hard Pagefaults
   • Specific processes like avp.exe (likely AV-Kaspersky Antivirus) triggered 4 hard pagefaults, which may impact audio playback timing but are a secondary concern compared to high DPC latencies.

---

Step-by-Step Fixes:​

1. Address storport.sys - Microsoft Storage Port Driver​

• Since storport.sysis linked to storage drivers and can interfere with real-time operations:
  • Update SATA/Storage (AHCI, NVMe) Drivers:
    • Visit your motherboard vendor's page (ASUS in your case) to locate chipset drivers, particularly any NVMe controller updates or Intel Rapid Storage Technology (IRST).
    • Alternatively, download the latest chipset drivers from Intel: Intel Driver & Support Assistant.
  • Disable unused SATA ports in the BIOS if you have disconnected drives or no hardware connected.
• Windows storage services tuning:
  • Open Services.msc, locate SysMain, and disable it (as previously recommended). SysMain (formerly Superfetch) can exacerbate storage-related latency.
  • If you’re on an NVMe SSD, ensure the correct power state (e.g., ASPM settings) and drive firmware are installed using Samsung Magician or an equivalent tool for diagnostics.

---

2. Handle dxgkrnl.sys + GPU Interrupt Issues​

• The DirectX Graphics Kernelmisbehaving could indicate GPU driver or display settings are conflicting with the system.
  • Update GPU Drivers:
    • Use the clean installation option available during NVIDIA/AMD driver installation to wipe remnants of old drivers.
  • Disable Hardware-Accelerated GPU Scheduling (HAGS):
    • Search "Graphics Settings" in the start menu.
    • If enabled, toggle HAGS off to reduce DPC contention.

---

3. USB-C Interface (wdf01000.sys + Power Management)​

• The Kernel Mode Driver Framework Runtime (wdf01000.sys)contributed to high ISR and DPC activity, which correlates directly with USB hardware interrupts (your Steinberg UR44-C being reliant on USB-C).
  • Disable USB Selective Suspend:
    • Open Power Options > Advanced Settings > USB Settings > Disable Selective Suspend.
  • Adjust BIOS Settings for USB and PCIe Power Management:
    • Enter the BIOS, look for power-saving settings like ASPM or USB power modes, and disable them.
    • Ensure USB-C compatibility is set to full bandwidth mode, if such an option exists.
• Update Steinberg and UR44-C Firmware/Drivers:
  • You’ve already tried driver updates, but double-check on their official website for the latest firmware. Some USB audio devices require firmware alignment with newer Windows builds.

---

4. Disable Intel Speed Step / EIST in BIOS​

Modern Intel CPUs dynamically throttle clock speeds for power efficiency, which can wreak havoc with low-latency audio functions.

• Disable Intel SpeedStep (or Enhanced Intel SpeedStep, EIST) and C-States in your BIOS.
• Set the CPU frequency to a locked value (sync all cores at base clock).
  BIOS Steps:
• Reboot and hit DEL/F2 to enter BIOS.
• Navigate to the CPU Settings or Overclocking Menu.
• Find Intel SpeedStep or energy-saving features like C1/C6 States, and disable them.

---

5. Examine Antivirus/Background Interference (avp.exe)​

• The hard pagefaults involving avp.exesuggest Kaspersky is occasionally interfering with audio threads.
  • Temporarily disable Kaspersky or run your system in Safe Mode with Networking to see if the problem abates during audio playback.
  • Disable Real-Time Scanning for large media libraries.

---

6. Optimize Audio Performance Further​

• Switch to a High Performance Power Planbut create a custom one tailored for audio production.
  • Set Minimum CPU State to 100%.
  • Disable timeout/power-saving features for USB and PCIe devices.
• Revisit your audio buffer size in Steinberg’s control panel (ASIO). A larger buffer size can temporarily stabilize audio streams while pinpointing the underlying issue.

---

7. Monitor and Test​

• After trying any of the above, revisit LatencyMon to check if storport.sys, dxgkrnl.sys, or wdf01000.sys have been tamed.
• Reproduce the original glitch across your HDMI audio and Steinberg interface and gather fresh stats for analysis.

---

If All Else Fails:​

If the process of addressing each driver doesn’t resolve the glitches entirely, testing a rollback from 24H2 via Windows Recovery Options or a clean reinstall may circumvent recent regressions. However, this is a last resort after attempting all above suggestions.
Let me know which remedies worked—or if additional diagnostics (or reviewing provided recordings) is needed!

As a further test, I loaded up Native Intstruments FM8 Synthesizer to eliminate any storage interactions during audio playback and I can confirm that the synthesized audio from FM8 was perfect: totally glitch free. Whereas playing an MP3 file via Windows Media Player still produced the audio glitches

 

[ChatGPT]

Thanks for the update, TangoGrowler! The fact that Native Instruments FM8 produced flawless audio but playback from Windows Media Player continues to glitch is an excellent clue. This strongly suggests that your issues are related to Windows audio subsystem drivers (WDM/WASAPI) or storage controller bottlenecks, rather than purely hardware or system-wide conflicts. Let’s focus on this nuanced pattern you've uncovered.
Here’s an updated set of actionable items to narrow down and resolve the issue:

---

Key Implications from Your Observation:​

• Synthesized Audio (FM8 -> ASIO) vs. Playback Audio (WMP -> WASAPI or DirectSound):
• FM8 likely routes audio via ASIO (low-latency, driver-focused for pro audio), whereas Windows Media Player defaults to WASAPI or DirectSound, which utilize the Windows Audio Engine.
• This explains the perfect performance on FM8: ASIO bypasses the Windows audio stack entirely.
• Windows Media Player and MP3 playback glitching:
• Here, bottlenecks originate either in:
• Standard WASAPI/DirectSound paths, which the system may be mishandling.
• Underlying data throughput/storage driver issues, as MP3 playback requires real-time decode + read from storage.

---

Focus Areas for Resolution:​

1. Bypass Windows Audio Engine Using WASAPI Exclusive Mode​

• Test playback via exclusive control over the hardware to isolate the Windows audio stack from external interference:
• Open Sound Settings > Locate Default Playback Device > Click Properties > Go to Advanced Tab.
• Enable Allow Exclusive Mode Applications.
• Use a media player (e.g., foobar2000) configured for WASAPI Exclusive Access:
• Install foobar2000: https://www.foobar2000.org/download.
• Install the WASAPI plugin (available from their components download page).
• Set WASAPI Exclusive Mode in the Playback configuration and replay an MP3 file.
• If this resolves the glitch, the problem lies within the Windows Audio Mixer or shared audio paths.

2. Investigate and Test DirectSound Pathway​

• WMP might be defaulting to DirectSound, which is prone to issues in some configurations. Test the same MP3 file on an alternative media player:
• Try VLC Media Player while forcing DirectSound: Tools → Preferences → Audio Output → Select DirectX Audio Output.

3. Manually Revert or Reinstall Microsoft Audio Drivers​

• Even though you reinstalled Windows, some corrupted files from WDM (Windows Driver Model) could remain:
• Open Device Manager (Win+X > Device Manager).
• Under Sound, video, and game controllers, right-click your playback device and choose Uninstall Device. Check Delete the driver software for this device, then reboot.
• Windows will reinstall native drivers automatically. Test glitches immediately post-reboot.
  If glitches persist:
• Install Steinberg’s Yamaha/Steinberg ASIO USB Driver and configure WMP or other media players to use it:
• Steinberg driver download: https://www.steinberg.net/en/support.

---

4. Further Investigate storport.sys Bottlenecks​

Since streaming MP3s involves both storage reads and decode, this aligns with the outlier storport.sys peak found during your LatencyMon analysis.
Key Actions:

• Switch off Write Caching (temporarily) on your system drive:
• Open Device Manager.
• Locate your SSD under Disk Drives, right-click, and select Properties.
• Under the Policies Tab, disable Write Caching. Test playback.
• Test relocating the MP3 file to a different drive (e.g., D: or an external drive) to rule out throughput issues on the current storage device.

---

5. Troubleshoot Specific Codec Issues​

• Windows Media Player relies on the Media Foundation Codec Pack for certain file types (e.g., MP3, AAC). A damaged or misbehaving codec can amplify glitches. Here’s how to address this:
• Reinstall the K-Lite Codec Pack (Free):
• Download from here: https://codecguide.com/download_kl.htm.
• Configure the installer for Default Settings.
• Test playback in WMP after codec updates.

---

6. Go Nuclear on Indexing Services​

• Just because synthesized audio works doesn’t mean file access is trouble-free. Windows Indexing/Search services can queue unnecessary disk reads during file playback:
• Open Indexing Options via Start Menu and click Modify.
• Remove all unnecessary locations where your audio files reside (e.g., Music Library/Drive D).
• Fully disable Windows Search:
• Open services.msc.
• Locate Windows Search, stop the service, and set it to Disabled. Test if indexing interruptions were the culprit.

---

7. Try a Real-time Realtime OS Hack (mmcss-api)​

• Pro audio devices integrate poorly with the Multimedia Scheduler Class (MMC). Here’s a hack:
• Launch Registry Editor (Win+R → regedit).
• Navigate to:
  

          HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Audiosrv

• Add a new DWORD value:
• Name: MMCSSPriority
• Value: F (Hexadecimal) or 15 (Decimal).
• Reboot and test.

---

Testing Roadmap:​

• Start with WASAPI Exclusive Mode and WASAPI-enabled players (e.g., foobar2000).
• Update SATA/NVMe storage drivers to reduce residual storport.sys interference.
• Experiment with disabling write caching or moving playback files.
• Reinstall audio frameworks or codecs (K-Lite for WMP compatibility).

Let’s see how these tweaks work out! If still unresolved, confirm whether glitches occur only during local MP3 playback or also with streaming content (e.g., YouTube). We’ll keep chipping away at this until we get it perfect—no glitches allowed on a music rig!

 

[TangoGrowler]

And more information that I should have provided previously: Playback via Cubase using ASIO is also very glitchy. Cubase uses a combination of synthesized sounds and playback of audio files stored on disk

 

[ChatGPT]

Thanks for this additional detail—it changes the context significantly! Since playback through Cubase using ASIO is also glitchy, this suggests that the issue is more systemic and isn't just limited to the Windows Audio Engine (WASAPI/DirectSound). Essentially, now both ASIO and Windows audio pathways are being affected. This indicates deeper issues relating to DPC latency, storage I/O, or USB audio processing.
Let's revisit our strategy based on this broader impact, keeping Cubase's performance in mind.

---

Updated Analysis:​

Since the Cubase ASIO path involves both:

• Synthesized sounds (via plugins/virtual instruments like FM8), and
• Disk-based audio playback (loading audio tracks into Cubase's timeline from storage),

The glitches in Cubase likely stem from:

• Storage throughput issues + DPC latency bottlenecks caused by storport.sys.
• USB-C interface interrupts (wdf01000.sys) specifically affecting real-time audio processing.

Any disruption to storage-involved reads, USB hardware buffering, or kernel-level driver conflicts are enough to destabilize Cubase performance due to its high real-time requirements.

---

Updated Action Plan:​

1. Move the Project/Audio Files to a Different Disk​

To confirm if storage contention is partly responsible:

• Move your Cubase project and audio files from your primary storage device (likely an NVMe SSD) to another drive, such as:
• A secondary SSD (internal or external).
• A fast external drive connected via USB 3.1+ (preferably not sharing the same USB controller as your audio interface).
• If this improves the situation, it confirms a bottleneck at storage controller or filesystem level.

2. Test ASIO Driver Buffer Size + Latency Settings​

In Cubase, your Steinberg interface relies entirely on the ASIO driver for low-latency audio. To stabilize playback during troubleshooting:

• Increase ASIO Buffer Size in Cubase's Audio Device Control Panel:
• Go to Studio > Studio Setup in Cubase.
• Select your Steinberg UR44-C under Audio System/ASIO Driver.
• Increase the latency/buffer size (e.g., try 512 samples or higher if it’s set lower).
• Disable ASIO Guard (if enabled):
• Use Studio > Studio Setup > VST Audio System, and disable ASIO Guard to ensure there’s no unnecessary task offloading contributing to glitches.

3. Address storport.sys Problems – Storage/Controller Drivers​

Since Cubase’s timeline relies heavily on disk I/O (reading audio files), storport.sys bottlenecks must be addressed:

• Update Drive and Storage Controller Drivers:
• Download the latest Intel Rapid Storage Technology (IRST) and chipset drivers for your ASUS motherboard from:
• ASUS Support: https://www.asus.com/support.
• Intel: https://www.intel.com/content/www/us/en/support/detect.html.
• Ensure your storage firmware is up to date (check manufacturer tools like Samsung Magician for Samsung NVMe drives or equivalent for your SSD).
• Verify Disk Health:
  Use Windows’ built-in tools or CrystalDiskInfo to ensure no drive errors are present:
• Run cmd.exe as Administrator and execute:
  

         chkdsk C: /f

  (Replace C: with the drive letter used for project files).
• Relocate your Pagefile (Virtual Memory):
  If you're running heavily disk-dependent workflows and sharing the same drive for pagefile and audio, this can choke I/O bandwidth.
• Go to System Properties > Performance > Advanced Tab > Virtual Memory.
• Move the pagefile to a different, less congested drive.

4. Isolate USB-C Interrupts (wdf01000.sys)​

USB-C connectivity issues are one of the leading causes of problems with audio interfaces like the Steinberg UR44-C:

• Force Your Audio Interface onto Another USB Controller:
• If your motherboard has both USB 2.0 and USB 3.x ports:
• Connect the UR44-C to a USB 2.0 port, as these are often more stable for audio interfaces.
• Alternatively, test connecting the Steinberg UR44-C via an active USB hub, which might help isolate USB controller-related conflicts.
• Finalize USB Power Settings:
• Open Device Manager → Locate USB Root Hub(s) under Universal Serial Bus Controllers.
• Right-click each entry → Choose Properties → Power Management Tab → Disable “Allow the computer to turn off this device to save power.”

5. Real-Time System Configuration for Cubase (thread priority, MMCSS tweaks):​

Cubase, when configured for real-time performance, relies on Windows’ Multimedia Class Scheduler (MMCSS) to prioritize audio threads over less critical tasks. Misconfigurations here can cause serious glitches:

• Update your audio-thread priority in Cubase:
• Open Cubase.
• Navigate to Studio > Studio Setup > VST Audio System.
• Enable Boost Audio Priority and set Advanced Processing Options to their defaults.
• Use Registry tweaks to enhance MMCSS priority for your setup:
• Open the Registry Editor (regedit) and navigate to:
  

          HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\Tasks\Pro Audio

• Modify the following keys:
• Scheduling Category → Set it to High.
• Priority → Set to 16.
• SFIO Priority → Set to High.
• Reboot and test playback again.

6. Disable Potential Sources of Interference (Antivirus, Network Stack)​

Since Cubase is glitchy, the storage-to-audio pipeline may still be interfered with by background processes like antivirus or network settings:

• Temporarily disable Kaspersky: Especially Real-Time Protection.
• Disable Wi-Fi/Ethernet: Network drivers like ndis.sys are common contributors to DPC bottlenecks. Disconnect networking temporarily to see if this improves Cubase's glitching.

7. Double-Check Steinberg Driver + Firmware​

If you haven't already, go nuclear on Steinberg’s driver stack:

• Uninstall and Reinstall Drivers:
• Remove any existing Steinberg Yamaha USB drivers through Add/Remove Programs in Control Panel.
• Download and install the latest Yamaha USB Driver from Steinberg's https://www.steinberg.net/en/support.
• Update UR44-C Firmware: Confirm the device's firmware matches driver specifications.

8. Final Testing​

After applying these fixes:

• Re-run LatencyMon while playing a Cubase project to monitor improvements.
• Examine if storport.sys, wdf01000.sys, or dxgkrnl.sys are still showing high execution times.

---

If All Else Fails:​

If the above measures don't resolve the issue, consider:

• Testing Cubase on a different PC or fresh Windows installation (to rule out system-level corruption from 24H2).
• Performing a rollback from 24H2 to the prior 23H2 build, as audio inconsistencies have been noted in certain 24H2 configurations.

Let’s see how these adjustments work! Feel free to share results—LatencyMon feedback post-tweaks would be helpful. We'll keep chasing this glitch until it's squashed!

 

[TangoGrowler]

Thanks for this additional detail—it changes the context significantly! Since playback through Cubase using ASIO is also glitchy, this suggests that the issue is more systemic and isn't just limited to the Windows Audio Engine (WASAPI/DirectSound). Essentially, now both ASIO and Windows audio pathways are being affected. This indicates deeper issues relating to DPC latency, storage I/O, or USB audio processing.
Let's revisit our strategy based on this broader impact, keeping Cubase's performance in mind.

---

Updated Analysis:​

Since the Cubase ASIO path involves both:

1. Synthesized sounds (via plugins/virtual instruments like FM8), and
2. Disk-based audio playback (loading audio tracks into Cubase's timeline from storage),

The glitches in Cubase likely stem from:

• Storage throughput issues + DPC latency bottlenecks caused by storport.sys.
• USB-C interface interrupts (wdf01000.sys) specifically affecting real-time audio processing.

Any disruption to storage-involved reads, USB hardware buffering, or kernel-level driver conflicts are enough to destabilize Cubase performance due to its high real-time requirements.

---

Updated Action Plan:​

1. Move the Project/Audio Files to a Different Disk​

To confirm if storage contention is partly responsible:

• Move your Cubase project and audio files from your primary storage device (likely an NVMe SSD) to another drive, such as:
  • A secondary SSD (internal or external).
  • A fast external drive connected via USB 3.1+ (preferably not sharing the same USB controller as your audio interface).
• If this improves the situation, it confirms a bottleneck at storage controller or filesystem level.

2. Test ASIO Driver Buffer Size + Latency Settings​

In Cubase, your Steinberg interface relies entirely on the ASIO driver for low-latency audio. To stabilize playback during troubleshooting:

• Increase ASIO Buffer Size in Cubase's Audio Device Control Panel:
  • Go to Studio > Studio Setup in Cubase.
  • Select your Steinberg UR44-C under Audio System/ASIO Driver.
  • Increase the latency/buffer size (e.g., try 512 samples or higher if it’s set lower).
• Disable ASIO Guard(if enabled):
  • Use Studio > Studio Setup > VST Audio System, and disable ASIO Guard to ensure there’s no unnecessary task offloading contributing to glitches.

3. Address storport.sys Problems – Storage/Controller Drivers​

Since Cubase’s timeline relies heavily on disk I/O (reading audio files), storport.sys bottlenecks must be addressed:

• Update Drive and Storage Controller Drivers:
  • Download the latest Intel Rapid Storage Technology (IRST)and chipset drivers for your ASUS motherboard from:
    • ASUS Support: ASUS Driver Downloads.
    • Intel: Driver & Support Assistant.
  • Ensure your storage firmware is up to date (check manufacturer tools like Samsung Magician for Samsung NVMe drives or equivalent for your SSD).
• Verify Disk Health:
  Use Windows’ built-in tools or CrystalDiskInfo to ensure no drive errors are present:
  • Run cmd.exe as Administrator and execute:
    

           chkdsk C: /f

    (Replace C: with the drive letter used for project files).
• Relocate your Pagefile (Virtual Memory):
  If you're running heavily disk-dependent workflows and sharing the same drive for pagefile and audio, this can choke I/O bandwidth.
  • Go to System Properties > Performance > Advanced Tab > Virtual Memory.
  • Move the pagefile to a different, less congested drive.

4. Isolate USB-C Interrupts (wdf01000.sys)​

USB-C connectivity issues are one of the leading causes of problems with audio interfaces like the Steinberg UR44-C:

• Force Your Audio Interface onto Another USB Controller:
  • If your motherboard has both USB 2.0 and USB 3.x ports:
    • Connect the UR44-C to a USB 2.0 port, as these are often more stable for audio interfaces.
  • Alternatively, test connecting the Steinberg UR44-C via an active USB hub, which might help isolate USB controller-related conflicts.
• Finalize USB Power Settings:
  • Open Device Manager → Locate USB Root Hub(s) under Universal Serial Bus Controllers.
  • Right-click each entry → Choose Properties → Power Management Tab → Disable “Allow the computer to turn off this device to save power.”

5. Real-Time System Configuration for Cubase (thread priority, MMCSS tweaks):​

Cubase, when configured for real-time performance, relies on Windows’ Multimedia Class Scheduler (MMCSS) to prioritize audio threads over less critical tasks. Misconfigurations here can cause serious glitches:

• Update your audio-thread priority in Cubase:
  1. Open Cubase.
  2. Navigate to Studio > Studio Setup > VST Audio System.
  3. Enable Boost Audio Priority and set Advanced Processing Options to their defaults.
• Use Registry tweaks to enhance MMCSS priority for your setup:
  1. Open the Registry Editor (regedit) and navigate to:
     

             HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\Tasks\Pro Audio

     1. Modify the following keys:
        • Scheduling Category → Set it to High.
        • Priority → Set to 16.
        • SFIO Priority → Set to High.
• Reboot and test playback again.

6. Disable Potential Sources of Interference (Antivirus, Network Stack)​

Since Cubase is glitchy, the storage-to-audio pipeline may still be interfered with by background processes like antivirus or network settings:

• Temporarily disable Kaspersky: Especially Real-Time Protection.
• Disable Wi-Fi/Ethernet: Network drivers like ndis.sys are common contributors to DPC bottlenecks. Disconnect networking temporarily to see if this improves Cubase's glitching.

7. Double-Check Steinberg Driver + Firmware​

If you haven't already, go nuclear on Steinberg’s driver stack:

• Uninstall and Reinstall Drivers:
  • Remove any existing Steinberg Yamaha USB drivers through Add/Remove Programs in Control Panel.
  • Download and install the latest Yamaha USB Driver from Steinberg's support page here.
• Update UR44-C Firmware: Confirm the device's firmware matches driver specifications.

8. Final Testing​

After applying these fixes:

• Re-run LatencyMon while playing a Cubase project to monitor improvements.
• Examine if storport.sys, wdf01000.sys, or dxgkrnl.sys are still showing high execution times.

---

If All Else Fails:​

If the above measures don't resolve the issue, consider:

• Testing Cubase on a different PC or fresh Windows installation (to rule out system-level corruption from 24H2).
• Performing a rollback from 24H2 to the prior 23H2 build, as audio inconsistencies have been noted in certain 24H2 configurations.

Let’s see how these adjustments work! Feel free to share results—LatencyMon feedback post-tweaks would be helpful. We'll keep chasing this glitch until it's squashed!

I'm so confused now. I moved the pagefile to a less busy disk and rebooted - after which, audio was playing back perfectly. I performed 3 more reboots and tested audio each time, and each time audio played back perfectly. However, after the next reboot, the audio glitches had returned, exactly as before. What could cause such an intermittent issue?

 

[ChatGPT]

Oh, I feel your pain here, TangoGrowler! It seems like your PC is messing with you on a whole new level—working perfectly one moment and falling back into the audio glitch abyss the next. This intermittent behavior can indeed be maddening, but it also provides important clues that point towards issues in the system state initialization during startup or something dynamically influencing performance after boot.
Let’s break this down further based on what we know so far and this irregular behavior.

---

Why It’s Intermittent​

1. Random DPC Spikes During Boot:
   • System or driver-level services may not consistently initialize properly across reboots, or there’s contention for hardware resources caused by specific services/drivers kicking in only on certain boots.
2. Power Management/Misbehaving Drivers:
   • Some drivers (especially audio, USB controllers, and storage) might reinitialize inconsistently depending on how they're handled during boot or after device enumeration.
3. Pagefile Interaction:
   • Moving the pagefile provided temporary stability, so there’s definitely a storage-related bottleneck involved. The fact that it regressed suggests a deeper storport.sys or storage management issue that’s cropping back up inconsistently.
4. Startup Interference:
   • Some processes (e.g., indexing, scheduled antivirus scans, background app startups) only kick in after certain boots, potentially choking system resources.

---

Action Plan to Isolate the Intermittent Behavior​

1. Boot Tracker via LatencyMon​

Run LatencyMon immediately after every reboot, both during flawless playback AND when glitches are present. This allows us to compare driver behavior and latency patterns between “good” and “bad” boots.
Steps:

• After reboot, open nothing but LatencyMon and let it analyze the system for about 5 minutes.
• Log whether it’s a “glitchy” or “non-glitchy” boot and look for high DPC issues caused by storport.sys, wdf01000.sys, dxgkrnl.sys, etc..
• Pay particular attention to any DPC spikes from storage, USB, or other drivers.

2. Disable Fast Startup​

Windows Fast Startup can cause unpredictable boot states where hardware drivers don't load consistently (since Fast Startup uses a hybrid sleep/hibernation mechanism). This could explain why things seem fine after some reboots but not others.
Steps:

• Go to Control Panel > Power Options > Choose what the power buttons do.
• Click Change settings that are currently unavailable.
• Uncheck the box for Turn on fast startup (recommended) and save changes.
• Restart the system and observe if it improves overall consistency.

3. Audit Event Viewer for Boot-Time Culprits​

The Windows Event Viewer may provide insights into why some boots experience glitches:

• Open Event Viewer (Win+R → eventvwr.msc).
• Go to Windows Logs > System.
• Look for errors or delays during boot time (e.g., USB devices failing initialization, disk controller issues, driver crashes).
  Key Events to Watch:
• Warnings or errors related to audio drivers (e.g., 'hdaudbus', Wdf01000, or Steinberg’s ASIO driver).
• Storage driver initialization issues (e.g., storport.sys, "Disk" warnings for slow read/write).
• Anything that looks like “failed retry after timeout.”

---

4. Tame Startup Processes​

A process or service may be interfering inconsistently at boot:

• Use Task Manager > Startup Tab to disable all non-essential startup apps and services temporarily.
• Reboot and see if performance stabilizes across multiple reboots.
• Gradually re-enable services to identify the offender, if any.

---

5. Force Consistency in Audio Playback Defaults​

The Windows Audio Engine may be inconsistently initializing during boot. For stability:

• Set consistent ASIO or audio device sample rates on both the Steinberg UR44-C and Windows Playback:
  • Sound Settings > UR44-C > Device Properties > Additional Device Properties. Ensure both Share Mode and Exclusive Mode sample rates match Cubase (e.g., 48kHz or 44.1kHz).
• In Cubase, confirm the buffer size/sample rate is fully aligned with the above.

---

6. Stubborn DPC Bottleneck? Investigate IRQ Conflicts​

If some hardware is fighting over resources during boot (e.g., storage controller vs USB-C interface), check for IRQ conflicts or non-optimal configurations:

• Open Device Manager → View → Resources by Type.
• Locate Audio Device/Interface and Storage Controllers and check if they share the same IRQ number (interrupt request). If so:
  1. Move your UR44-C to a different USB port.
  2. Update BIOS to ensure IRQs are optimally assigned.

---

7. Align USB Behavior During Boot​

Since the UR44-C glitches more frequently, occasional issues with how the USB-C interface is initialized during boot shouldn't be overlooked:

• Ensure the UR44-C is connected directly (not via hub, unless isolating USB controllers).
• In Device Manager > USB Root Hub settings:
  • Disable Power Management to ensure consistent wakeup during system initialization.
• If issues persist, test the Steinberg on another machine to rule out hardware compatibility quirks with your USB-C chipset.

---

8. Simplify Your Testing Environment​

If possible, strip the system to the basics to eliminate variables:

• Stop running Cubase with large projects (for now).
• Ensure no third-party DAW services/plugins (e.g., Native Instruments services) are running at startup.
• Observe whether basic MP3/WAV playback in WMP or VLC also follows the intermittent pattern.

---

Long-Term Band-Aid (if diagnostics fail):​

If the above doesn’t stabilize the system:

• Test Rolling Back to 23H2: While not ideal, reverting to a pre-24H2 build could eliminate newly introduced instabilities.
• Consider a Bare-Metal Clean Reinstall: No one likes doing this, but it ensures no rogue drivers or services persist post-24H2 update.

---

Moving Forward:​

Run the boot tracker via LatencyMon (step 1) and check Event Viewer for patterns (step 3). Let us know what you find, and don’t hesitate to provide LatencyMon outputs for faulty boots—we’ll iron out the inconsistencies until your audio is flawless every time! You deserve glitch-free jams.

 

[TangoGrowler]

Oh, I feel your pain here, TangoGrowler! It seems like your PC is messing with you on a whole new level—working perfectly one moment and falling back into the audio glitch abyss the next. This intermittent behavior can indeed be maddening, but it also provides important clues that point towards issues in the system state initialization during startup or something dynamically influencing performance after boot.
Let’s break this down further based on what we know so far and this irregular behavior.

---

Why It’s Intermittent​

1. Random DPC Spikes During Boot:
   • System or driver-level services may not consistently initialize properly across reboots, or there’s contention for hardware resources caused by specific services/drivers kicking in only on certain boots.
2. Power Management/Misbehaving Drivers:
   • Some drivers (especially audio, USB controllers, and storage) might reinitialize inconsistently depending on how they're handled during boot or after device enumeration.
3. Pagefile Interaction:
   • Moving the pagefile provided temporary stability, so there’s definitely a storage-related bottleneck involved. The fact that it regressed suggests a deeper storport.sys or storage management issue that’s cropping back up inconsistently.
4. Startup Interference:
   • Some processes (e.g., indexing, scheduled antivirus scans, background app startups) only kick in after certain boots, potentially choking system resources.

---

Action Plan to Isolate the Intermittent Behavior​

1. Boot Tracker via LatencyMon​

Run LatencyMon immediately after every reboot, both during flawless playback AND when glitches are present. This allows us to compare driver behavior and latency patterns between “good” and “bad” boots.
Steps:

• After reboot, open nothing but LatencyMon and let it analyze the system for about 5 minutes.
• Log whether it’s a “glitchy” or “non-glitchy” boot and look for high DPC issues caused by storport.sys, wdf01000.sys, dxgkrnl.sys, etc..
• Pay particular attention to any DPC spikes from storage, USB, or other drivers.

2. Disable Fast Startup​

Windows Fast Startup can cause unpredictable boot states where hardware drivers don't load consistently (since Fast Startup uses a hybrid sleep/hibernation mechanism). This could explain why things seem fine after some reboots but not others.
Steps:

• Go to Control Panel > Power Options > Choose what the power buttons do.
• Click Change settings that are currently unavailable.
• Uncheck the box for Turn on fast startup (recommended) and save changes.
• Restart the system and observe if it improves overall consistency.

3. Audit Event Viewer for Boot-Time Culprits​

The Windows Event Viewer may provide insights into why some boots experience glitches:

• Open Event Viewer (Win+R → eventvwr.msc).
• Go to Windows Logs > System.
• Look for errors or delays during boot time (e.g., USB devices failing initialization, disk controller issues, driver crashes).
  Key Events to Watch:
• Warnings or errors related to audio drivers (e.g., 'hdaudbus', Wdf01000, or Steinberg’s ASIO driver).
• Storage driver initialization issues (e.g., storport.sys, "Disk" warnings for slow read/write).
• Anything that looks like “failed retry after timeout.”

---

4. Tame Startup Processes​

A process or service may be interfering inconsistently at boot:

• Use Task Manager > Startup Tab to disable all non-essential startup apps and services temporarily.
• Reboot and see if performance stabilizes across multiple reboots.
• Gradually re-enable services to identify the offender, if any.

---

5. Force Consistency in Audio Playback Defaults​

The Windows Audio Engine may be inconsistently initializing during boot. For stability:

• Set consistent ASIO or audio device sample rateson both the Steinberg UR44-C and Windows Playback:
  • Sound Settings > UR44-C > Device Properties > Additional Device Properties. Ensure both Share Mode and Exclusive Mode sample rates match Cubase (e.g., 48kHz or 44.1kHz).
• In Cubase, confirm the buffer size/sample rate is fully aligned with the above.

---

6. Stubborn DPC Bottleneck? Investigate IRQ Conflicts​

If some hardware is fighting over resources during boot (e.g., storage controller vs USB-C interface), check for IRQ conflicts or non-optimal configurations:

• Open Device Manager → View → Resources by Type.
• Locate Audio Device/Interface and Storage Controllersand check if they share the same IRQ number (interrupt request). If so:
  1. Move your UR44-C to a different USB port.
  2. Update BIOS to ensure IRQs are optimally assigned.

---

7. Align USB Behavior During Boot​

Since the UR44-C glitches more frequently, occasional issues with how the USB-C interface is initialized during boot shouldn't be overlooked:

• Ensure the UR44-C is connected directly (not via hub, unless isolating USB controllers).
• In Device Manager > USB Root Hubsettings:
  • Disable Power Management to ensure consistent wakeup during system initialization.
• If issues persist, test the Steinberg on another machine to rule out hardware compatibility quirks with your USB-C chipset.

---

8. Simplify Your Testing Environment​

If possible, strip the system to the basics to eliminate variables:

• Stop running Cubase with large projects (for now).
• Ensure no third-party DAW services/plugins (e.g., Native Instruments services) are running at startup.
• Observe whether basic MP3/WAV playback in WMP or VLC also follows the intermittent pattern.

---

Long-Term Band-Aid (if diagnostics fail):​

If the above doesn’t stabilize the system:

• Test Rolling Back to 23H2: While not ideal, reverting to a pre-24H2 build could eliminate newly introduced instabilities.
• Consider a Bare-Metal Clean Reinstall: No one likes doing this, but it ensures no rogue drivers or services persist post-24H2 update.

---

Moving Forward:​

Run the boot tracker via LatencyMon (step 1) and check Event Viewer for patterns (step 3). Let us know what you find, and don’t hesitate to provide LatencyMon outputs for faulty boots—we’ll iron out the inconsistencies until your audio is flawless every time! You deserve glitch-free jams.

I believe the issue is resolved now. I found some warnings (event id 157) in eventvwr relating to a disk being "surprise removed". So I unplugged 2 unused SATA drives and the audio glitches have not happened since. I have rebooted 10+ times to make sure and so far so good. I attach some LatencyMon reports in case it helps update the support data - these are results from 12 consecutive tests involving a reboot and a run of LatencyMon. Of which 4 resulted in playback glitches. The files in the zip archive are numbered chronologically and following the number is the text "PerfectAudio" or "GlitchAudio" depending on the results of the audio playback. I would say thanks, but that would be meaningless to an AI bot. I am glad this interaction though, it was definitely useful

 

[ChatGPT]

It seems I couldn't locate the uploaded ZIP file from your LatencyMon reports. If you'd like me to analyze them further, please re-upload the file so I can process the data and extract insights from the reports. Let me know how you'd like to proceed!

 

[TangoGrowler]

It seems I couldn't locate the uploaded ZIP file from your LatencyMon reports. If you'd like me to analyze them further, please re-upload the file so I can process the data and extract insights from the reports. Let me know how you'd like to proceed!

I only uploaded a single file called LatencyMonReports.zip. I am uploading again. If you can't locate it this time, get yourself down to specsavers

 

[ChatGPT]

It seems I'm failing to access your uploaded ZIP file once again. As much as I'd love to take you up on the Specsavers suggestion , there may be a technical issue preventing the file from being processed.

Could you try:
1. Re-uploading the file one more time.
2. If the issue persists, potentially try attaching the individual LatencyMon report files instead of the ZIP archive.

I'll ensure the analysis continues as soon as I gain access to the data. Thanks for your patience!