Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Loss of HDMI Audio output on pc/receiver standby – problem and solution (Read 1216 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Loss of HDMI Audio output on pc/receiver standby – problem and solution

Since changing my Foobar2000 source from a PC with SPDIF output to an NUC with Intel Audio HDMI, I have been having a problem with loss of the HDMI output in Foobar when my Emotiva MC700 DAC/processor is switched back on out of standby. I have now fixed this and as the solution is rather obscure and was very difficult to find I thought I should record it here in case it helps other users who may come across this post in the future.

Setup: My NUC is always on, connected to the processor via HDMI. Foobar2000 is always running, minimized, and controlled by FoobarCon Pro from Android and MonkeyMote from iOS so that there is no need to switch the screen on to play music – I just switch the Emotiva processor on out of standby, set to the correct input and start playback using the Android/iOS device.

Symptom: Since changing from my previous SPDIF connected setup to HDMI, when the Emotiva processor has been in standby for more than a short time Foobar2000 “loses” the soundcard in Output. When the screen is switched on the NUC is seen to be correctly showing the Emotiva processor as present and connected, but the output field in Foobar2000 preferences is just blank although the dropdown box correctly shows all the right soundcard options are available. Effectively, Foobar appears to have noticed that the Emotiva processor has gone while it is in standby and gives up on it so it does not automatically return to it when the processor is switched back on. This behavior is the same even if the setup is left to figure things out for a minute or two after the processor is switched on before trying to play something. This behavior is also the same whether the output chosen in Foobar is WASAPI or DS for the processor, or just Default Sound Card.

Solution: After trying various things I came across this post about Kodi, dealing with similar issues arising when either PC or receiver/processor is switched to sleep/standby:

https://forum.kodi.tv/showthread.php?tid=251833

The thread states that Windows requires the EDID - Extended Display Identification Data - from a device to conform to HDCP  to eliminate the possibility of digital data manipulation midstream between the source and display. Without the EDID, the device does not exist. Resuming from Sleep often breaks the handshake between PC and display. HDCP intervenes, and sound is disabled.

The fix is to use an EDID override which replaces the HDMI handshake by giving the display device a permanent identity and thereby, a permanent connection to the PC. The device no longer has to "check-in" when Windows resumes from sleep and maintains its full functionality as if its normal EDID is present. Creating an EDID override involves creating an INF file with the relevant display info and loading it as a new driver in Windows. This file can be created automatically by a program called MonInfo. Since the process is quite detailed and extremely well described in that article, I shall not repeat it here.

Although my problem was caused by the processor/receiver sleeping, not the pc, the issue was the same and the fix was the same. Since making the changes described, my system is working perfectly.