HDAudBus.sys excessive ISRs

[john909]

Hello all, found this excellent site when troubleshooting my computer's performance issues.

This is a fresh Windows 10 (1803) with the latest available drivers installed and only some games for testing. Detailed hardware information in this Html file.
It all started after experiencing stuttering on an Nvidia 1080Ti which is a powerful card and the games I was testing should run without any issues at all.

After a lot of reading I changed the Interrupt to MSI (Message Signaled Interrupt) mode and you could see the difference from the first moment, smoother framerate, no excessive stuttering, no high DPC times in LatencyMon for the nvlddmkm.sys (Nvidia Kernel Mode Driver). Still testing but the first impression was evident.

Then I watched the driver HDAudBus.sys. This file is installed along with the graphics card and is the driver that provides sound via HDMI. Now in my case there is only one sound interface active which is connected to the computer via Firewire so I try to understand the below picture:



The above is a snapshot of the computer operating with just a few chrome tabs open and for a duration of 30 seconds. In that short period the driver in question generated 26630 ISRs for which I don't understand the reason - my Monitor has no speakers and no sound is delivered through HDMI. Also disabling the device in the device manager does not stop the HDAudBus.sys generating ISRs.
I don't know if it's relevant but watching this closely I saw that when the HDAudBus.sys generates ISRs, the Wdf01000.sys also generates ISRs in the same rate - as if these two drivers work in parallel.

The purpose of learning more about it is both fine tuning my system and educational. Do you consider this behavior normal?

Any advice, opinion or recommendation will be greatly appreciated, thanks in advance.

 

[john909]

Forgot to add an .etl is a bit large but hope it will provide some more detail.

 

[cwsink]

Hi john909,

That does seem like a high number of audio related ISRs. Looking at the etl it would appear you're getting almost 1000 HDAudioBus.sys ISRs per second while my system generates 44 per second. I suspect mine is based on the playback frequency of 44.1 HZ while yours... I'm not really sure. Do you have a utility or program you use which records or plays audio back at 900+ Hz?

 

[john909]

Hey cwsink, thanks for your reply.


I checked my external sound card (Sounds/Playback/Properties) and it was somehow set to sample at 48Khz, reverted it to 44.1 but opening LatencyMon the same thing happens, ISRs occur in this fast rate even while I am just watching my desktop (no sounds generated). Now I did some more experiments with the available sound interfaces I have.

1. The external card connected and powered on= high ISR
2. The external card connected and powered on but not the default windows sound device (default is Corsair Void USB headset)= high ISR
3. The external card connected and disabled in device manager - default sound device Corsair Void= no ISR
4. Corsair Void Usb as default sound device - standalone= no ISR

So it seems that when the external card is connected and powered on, even if it's not the default sound device it generates these numerous ISRs. I can't understand how or why - I tried playing with its settings like Firewire Latency, MIDI clock setting or ASIO buffers but no different result.
(*could also try the on-board Realtek but I believe the issue is obvious)

Sad thing is I can't permanently disconnect the card as I have my studio monitors on it and also use it for recording. And I am also using the latest drivers.

 

[cwsink]

I’m wrong about my guess of a correlation between the rate at which my system is using the driver and the sampling rate. 48 KHz is DVD quality and 44.1KHz is CD quality and my system was set for DVD by default.

I get the impression HDAudBus.sys has a fairly descriptive filename (high definition audio bus) and can be used with many different things involving moving HD audio data through a system bus. I don’t get the impression it’s only involved with HDMI audio. Did you find documentation suggesting it’s only used for HDMI?

So, the more HD audio related work you’re doing with different audio devices the more often the ISR is going to be used. And not just devices, software could be using interrupts for HD audio processing as well. Yours looks high compared to my system but what you’ve written suggests you’re doing quite a bit more than basic audio playback while I simply played a video on Youtube for my trace.

LatencyMon can be helpful but I’ve seen it suggest there’s a problem where none exists. When LatencyMon was originally created Windows basically used one core for processing ISRs; always core 0. These days ISRs are better distributed amongst available cores and I’m not sure the developers of LatencyMon have taken that fully into account – just because there’s an ISR or DPC taking a long time doesn’t mean it’s a problem for media playback unless it’s blocking the thread trying to playback audio. The main concern, typically, would be if you’re hearing audio glitches (pops, crackles, etc.) during playback or your recordings contain glitches. Are you still experiencing audio glitches after the changes you made? If so, were you experiencing audio glitches while you recorded the etl trace you made available? I ask because the DPC and ISR graphs in the etl file don’t show anything which would suggest you should be. They look excellent, actually.

 

[john909]

You are right regarding the device the name misled me.



Looking at its parent:



look like a pci subsystem device probably feeding it sound information.

It all started getting out of "memory exception" errors (the game crashing) playing a fairly basic for today's standards DX9 game (Guild Wars 2). When this was happening the whole experience was sluggish to say the least. This game uses an old engine overloading core 0, so what I believe is that in the scenario where the CPU was getting beaten hard it was complaining with those exceptions.

Of course I also have to say that the previous installation, while it used the same set of driver, it may have become "dirty" as this was an installation since October 2015 (with all the major W10 updates patched), with some hardware changes in between (2 graphics cards AMD, Nvidia, an addition of a 3,5" hard disk). After resetting windows and till this moment, no errors in the game and the whole experience seems smoother.

I only see now high DPC spike times for the nvidia driver which was solved when 1080 Ti was set in MSI mode. But I rushed to get happy - for some strange reason battlefield 3 refuses to go full screen - Alt+Enter seems like working getting the borders expanding in a flash, but game still stays windowed. Even if I delete the MSI key from registry, the game still persists in windowed mode and only solution (so far) was to DDU the driver and reinstall it. Very strange.

Thanks again for your reply really helped me getting this into a path. :smile9: