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.