Why does the "Playback Devices" dialog take so long to open?

Question

Opening any of the audio properties dialogs takes 2 minutes and 5 seconds every time. There aren't other tasks that take an unreasonable amount of time. It's something specific to the Sound properties dialog. If I restart my computer, it will open immediately for the first day or 2.

It's likely a driver issue. I have an AMD graphics card with sound output (through HDMI), a Realtek audio chip on the motherboard, a USB microphone, and USB headphones. Is there a way to determine which one of these is misbehaving? Or a way to figure out what's holding things up when it's waiting?

Answer 1

http://www.overclock.net/t/903497/opening-playback-devices-is-slow suggests disabling audio device(s) in Device Manager.

---

Edit by Sean (the OP):

This article does not seem to be completely related. Their issues were with crossfire and sound over HDMI. However, disabling the "AMD High Definition Audio Device" in the Device Manager did work for me.

Answer 2

I fixed it with ATI HDMI Audio Device driver, tested in ATI/AMD 7850 and R9 270x from realtek for Windows 7 and 8.1.

Answer 3

I have the same problem and updating the audio driver from AMD didn't work, and in fact the update caused HDMI audio to stop working.

After reverting to the previous driver version I noticed that the problem is caused by using the HDMI audio when the TV is turned off. If I remember to switch it back to "Speakers" when the TV is turned off, it doesn't "break".

Answer 4

In my case, stopping AudioSrv, then disabling/enabling AMD HDMI audio, last resuming AudioSrv fixed the problem.

I had even took some ProcMon trace (as diligently suggested by magicandre1981) but the only hard discovery was that the window is opened by issuing "C:\Windows\System32\rundll32.exe" C:\Windows\System32\shell32.dll,Control_RunDLL C:\Windows\System32\mmsys.cpl

It seems like then this process goes through HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render AMD HDMI devices, checks their CLSID in HKLM\SYSTEM\CurrentControlSet\Control\MediaCategories (by querying the driver I guess? Since these were only defined in HDAudioInstall.e0VirtualEPOutputTopo section of the driver .inf)

... Ultimately stalling for like 6 seconds on my system, and proceeding like nothing was happened over HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses\{6994AD04-93EF-11D0-A3CC-00A0C9223196}\##?#HDAUDIO#FUNC_01&VEN_1002&DEV_whatever associated HDMI topology entry; so repeat on and on until all HDMI pins are passed.

EDIT: so, I had again this problem today and I took some further digging (with ProcExp this time), and I'm not even sure anymore it's a thing particularly just about the dialog in the first place. Rundll32 stack not only for some reason loads AtihdW76.sys (the driver) but also a fuckton of others HDAudBus.sys, portcls.sys, ks.sys, ksthunk.sys, MMDevApi.dll.... All stuff which is not there when it opens smoothly normal.

But more than anything, the problem seems to reside upstream, insofar as if I just reboot AudioSrv (without touching AMD HDMI device), it also takes a whole minute to start again too. Interestingly even when stopped, there are still 2 handles of it in svchost.

EDIT2: And for some reason, start and stopping HDMI devices.. also starts and stops many dhcp (yes, you read that right) instances in the same container.