[mythtv-users] NVidia HDMI Sound & Video gone after monitor (TV) sleep or disconnect [SOLVED]

[Kingsley Turner]

So I've had a lot of problems lately after upgrading my MythTV Box.

First and foremost is that whenever the monitor went to standby, or was 
turned off, or even the cable pulled, the video and audio signals from the 
NVidia (model 610, fanless) card would no longer connect back again.  It was 
as if the devices were physically disconnected.  The driver installed is the 
NVidia closed-source 346.96 (latest offered by package manager).

I have my system running through one of those switching power boards that 
disables a bunch of outputs when they see a particular socket's device go 
into a low-power state.  The TV is in this detecting socket, so whenever the 
TV sleeps, the amplifier and various other doo-dads are de-powered.   I like 
this because when the kids walk away after watching something, first the 
screensaver (of random family photos) kicks in for a while, but then the TV 
sleeps, which basically also turns off everything. The myth-box watches TV 
for us 24/7, but it does see its HDMI endpoint (the amplifier) go away 
whenever the TV sleeps, which leads to the problems.

Also FWIW, I had exactly the same problems with the video card connected 
directly to the TV - so it's not just some aspect of the 
MythTV->av-receiver->TV connection.


The solution to fixing the video, which seems to work 99% of the time, is to 
"hardcode" the TV (or amplifier) EDID signature into xorg.conf.  It should 
the the EDID of the next device after the video card.  So if the HDMI cable 
goes first into an amplifer/av-receiver then that.  If it goes straight to a 
TV, then the EDID of a TV.

First you need to use the nvidia-settings tool to save a copy of your output 
device's EDID
Then this is referenced from within your xorg.conf "Screen Section":

Section "Screen"
     [... all the other stuff]
     Option         "ConnectedMonitor" "DFP-1"
     Option         "CustomEDID" "DFP-1:/home/mythuser/onkyo_amp_edid.bin"
     Option         "IgnoreEDID" "false"
     Option         "UseEDID" "true"
EndSection

The "ConnectedMonitor" has to match where your device links.  This can be 
seen in the nvidia-settings GUI, but also found in /var/log/Xorg.0.log.  The 
"CustomEDID"  needs the path to where you saved the monitor's EDID data.

Obviously restart X11 (e.g. logout, reboot or something) for changes here to 
take effect.

Now sound is a tougher problem.  If you restart X (again, by logging out, 
rebooting) it comes back straight away.
I still do not know what the base problem here is.  I must have read a few 
hundred pages on teh internets, but found no real solution.
It's *not* a pulseaudio problem, since myth is configured not to use it.  It 
is something to do with alsa/X11/nvidia/hdmi ... I think.
Maybe you can poke at the sound driver, but I had no stomach with that.  
(HDMI sound is inextricably linked with video, there's a whole bunch of 
dependant modules to unload before you could consider unloading and 
re-loading the sound driver.)

Anyway, using the program 'xrandr' to temporarily turn the display off 
brings the sound back.

So a *workaround* that Works For Me, is to assign a key on your remote / 
keyboard to do this more easily.
I made a script "fix_hdmi_sound.sh":

#! /bin/sh
/usr/bin/xrandr -display :0 --output HDMI-0 --off
/bin/sleep 2
/usr/bin/xrandr -display :0 --output HDMI-0 --auto

This turns the display output off for 2 seconds (maybe you can tune this 
number), and when it's back on, so is the sound.  Again the "HDMI-0" comes 
from /var/log/Xorg.0.log.  But if you only have a single monitor, it's 
probably the above.

Since I use a keyboard as a remote, I used 'xbindkeys' to assign a hot-key 
to run this script.
So the bottom of my /home/mythuser/.xbindkeysrc has:

# Run the sound fix script on ALT-S
"/home/mythuser/fix_hdmi_sound.sh"
     alt + s

And xbindkeys is set to run on session start.  It defaulted to this when 
installed in Mythbuntu.

There's various examples of doing this with IR remote controls too, but I 
don't use one.

Hopefully in the longer-term none of this stuff will be necessary. But for 
the moment, this is what I do.
I hope the above information saves someone the long hours of research and 
experimenting.  :D


-kt


PS> What else can I try?

If you're googling for a solution, it helps quite a lot to click [Search 
tools] -> [Any time] -> [Past year] to get relevant results.  Many a time I 
thought I'd found the perfect solution, only to read it's dated 2003.  *sigh*

I did read some articles about the TV doing some HDMI handshaking back to 
the device, and the general suggestion was to turn this off.  I did turn 
this off on my TV (a circa 2011(?) samsung), but it made no difference.  
There is no way to turn this off on my av-receiver/amplifier.

You could probably also try the latest NVidia blob driver.  I did not do 
this because in years previous there was issues re-compiling the driver when 
the kernel updated, etc.  So it was a path I did not want to traverse.

On windows there's some developers kit module that allows you to unload and 
reload the video driver on the fly, i saw lots of references to that with XBMC.

Maybe the latest linux kernel?  But then you can also get NVidia driver 
mismatches.