When switching to a monitor profile that enables a previously disabled screen and changes the default audio device to that screen's HDMI connection (nvidia audio), it appears that a race condition occurs which sometimes results in the wrong audio device being selected. Furthermore, when this happens, audio will be changed to the display output for a different screen, even if that screen ends up being disabled in the target monitor profile. This prevents the audio device from functioning at all. Rebooting the computer or waking from sleep while the desired monitor profile is active resolves the problem temporarily. Is this the best place to report the bug? I am running version 9.4.3. Thanks.

Thank you for getting back to me. I upgraded to 9.5b2 and I haven't had this problem since. However, since it's intermittent, it might come up again after some time. I'll let you know if it happens in the future. Thanks again.

It turns out that this is still happening on 9.5b4. Did anything change in a recent beta, but it seemed better in 9.5b2. However, the problem is intermittent so it might be coincidence. It looks like a race condition to me.

Thank you very much! This problem hasn't occurred since I updated to v9.6 beta and it was happening consistently about 50% of the time before. It's intermittent so I'll keep testing. What was the problem? Was it a race?

Sorry, this is actually still happening at about the same rate as before. I thought it was fixed initally, but it is intermittent (although frequent). Please let me know if there's any additional information I can provide to help resolve this before the final release. Thanks.

Thanks. I'm happy to provide more specifics if it helps. I also found a new workaround that wasn't working before. If I open Windows Sound Settings after switching the monitor profile, it will enumerate audio devices and correct the problem. It's visually noticeable that audio devices are re-scanned because the options in the Sound Settings pulldown menu visually flicker and change while it scans. I'm not sure if this new workaround is the result of the new DisplayFusion version or perhaps a Windows update.

I installed the new version two days ago. I'll let you know if the problem happens again.

Unfortunately, this is still happening with 9.6.1. Opening Windows Sound Settings still resolves it. Does this rule out a race? Can you enumerate the audio devices the way Sound Settings does?

I've been trying the new version and the bug still seems the same. However, the delay you've added is now long enough for me to actually see when the audio sources change. Ever since the previous version, I've been usually (but not always) seeing a duplicate source in the audio devices list after the profile change is complete. This duplicate ends up being selected, but it does not output any audio. If I manually change to the correct device (not the duplicate), it works normally. As always, opening the Windows audio settings correctly enumerates the devices and resolves any issues, even if I open it before DF finishes switching profiles. Perhaps I will try deleting the monitor profile and adding it back to see if that resolves the issue?

At this point, it doesn't seem like increasing the delay before enumerating audio devices will resolve this. The delay is now so long that I have time to open the Windows audio settings before DF updates devices - and then DF gets it wrong. If it helps, it seems like it takes about 9 seconds for my other screen to wake up. I don't know what APIs you have access to, but can you think of any other solution besides adding a delay before updating the audio devices? Have you been able to reproduce this issue yourselves? I'd be happy to provide any details you need. Thanks.

I installed the new version and I'll let you know how it goes. Thanks for working on this!

Unfortunately, the problems appears the same after the latest updates. As always, opening Windows Sound Settings resolves the incorrect audio devices.

This bug was reported over a year ago and there really hasn't been any progress. Repeatedly increasing the lag time before enumerating audio devices didn't seem to help. Do you need any more information from me in order to reproduce the problem? Can you please devote some resources to this to fix it once and for all? Let me know how I can help. Thanks.

Have you been able to reproduce the issue at least? That would seem to be a necessary first step. Let me know if you need any more information to reproduce the problem. Thanks.

I'm currently testing to see if this is perhaps an nvidia bug instead. There was one instance where my screen went to sleep after inactivity, but I woke it before the system was suspended. In that case, the nvidia HDMI audio device disappeared just like when switching monitor profiles. After further research, I discovered that many nvidia users reported this behavior over the past couple years, especially with VR headsets. Apparently the issues has been reported to nvidia a couple years ago, but they have not resolved it.

The following reddit post contains a registry fix to work around this problem by adjusting the audio device power settings. I am currently testing the proposed solution and I will report back if the problem happens again.

https://www.reddit.com/r/ValveIndex/comments/c72pg0/discussion_and_troubleshooting_for_index_hardware/esmjkz4?utm_source=share&utm_medium=web2x&context=3

This has been pretty much confirmed to be an nvidia driver power HDMI management problem. It can be temporarily resolved by following the steps I linked to manually edit the registry. However, it always resurfaces after a driver upgrade. This seems like it could be a common problem for those who switch between multiple screens frequently. Even though this is not a DisplayFusion bug, would you consider adding a workaround into your software? You could periodically check and update the registry to work around the problem if the user enables that setting in DF. Thoughts?

Thanks for letting me know. In that case, would you be willing to implement a safer workaround instead? The issue happens frequently after a screen connected with HDMI wakes from its power save mode (not OS sleep), whether I'm switching between monitor configurations or not. However, I discovered I can always fix it by manually opening the Windows Sound Control Panel (not the Windows 10 Sound Settings). Can you automatically replicate whatever polling that the Sound Control Panel is doing a few seconds after a monitor wakes up? I realize this is not your bug, but I think a lot of multi-monitor users might suffer from this from time to time. I doubt nvidia will ever fix it. Thoughts?

Thanks for trying. I wonder what the Sound Control Panel is doing behind the scenes that fixes it.