We are currently performing some tests in order to replicate this situation.
As soon as we have the behavior of our system, we will be advising you with a possible resolution.
We already perform the tests mentioned before.
Hardware used: Intel® NUC Kit NUC5PGYHR
-Display with built it speakers: Asus VE278
We were able to get audio from the built in speaker after booting the device using the controller.
The audio device is not the same you are using, but, the interface and scenario is the same indeed.
Also, we were able to find some steps that may assist you with the situation.
1. The Audio output device has to be the desired one.
Please refer to the pictures below:
Make sure the Audio output device is properly selected.
It's not a sound problem. The Nuc does not display anything on hdmi. When powering on my AVR first, waiting about five seconds and then starting NUC, everything works fine. It is not a problem of openelec. There is no signal on hdmi when powering on simultanously. It should be implemented in bios that the signal is pushed to hdmi even if handshake is not possible.
When I use my Logitech Harmony remote, I can handle this problem with a workaround, but it would be nice if it can be fixed...
Have you tried putting this in your config.txt file:
The file should reside in either /boot/config.txt or /flash/config.txt. It depends upon the platform. On the Raspberry Pi, it's under /flash/config.txt. You may have to remount that filesystem to make it writable with something like:
mount -o rw,remount /flash or
mount -o rw,remount /boot
EDIT: I just booted up my OpenELEC SD card and it seems that the directory is /flash not /boot. It is mounted read only by default so you'll have to do the remount or put it in a Windows machine and create/modify the config.txt file. My install doesn't have the file present so it looks like you will have to create it.
You want to use VAAPI video acceleration, not VDPAU.
EDIT2: You can also caputure the EDID information from the AVR/display, write it to a file and force OpenELEC to use that instead of trying to pull it before everything is ready. I'm not sure how to do that though. You should probably be asking your question in the kodi forum. There are people there with tons of experience with this platform.
I think It does not depend on openelec.
About the config.txt: It might be used in rpis openelec, but I'm not sure, if it can be used on linux (x86). I will look up further info in openelec forum.
Did you try the Pin 19 trick?
Another option would be to see if the issue follows the OS, you could to try to replicate it in a different OS, it may be a different Linux based OS or Windows.
The other recommendation would be to check the Openelec forums for this situation as you previously said.
Do not hesitate to contact the Intel Communities again if additional or new inquiries are present.
I don;t believe that this is an O/S-level problem. If the BIOS disables the interface (because not seeing display device), there is nothing that the O/S can do. I come back to the original request: add an option to the BIOS to always initialize the display or add an option to the BIOS to implement a delay before testing for display device.
P.S. Can one of you people who are having this problem install Windows (at least temporarily) to see if the same thing happens? This would absolutely prove that it is something that needs to be solved at the BIOS level (or is a Linux issue)...
I found some threads in DENON and Openelec forums that may assist you with this situation.
Different people are having similar scenarios when using an AVR in their configuration.
Some advises or workarounds are in the forums found.
Regarding the Windows/test, I would like to hear from you guys if the tests are performed and the outcome present.
Forum's threads found:
I did a simple test today using my NUC5PPYH and a Mythbuntu installation. Starting from a power off condition, I removed the HDMI cable leaving nothing plugged in. I booted the device and waited for it to finish starting up. I plugged in the HDMI cable and the monitor responded, but went back to sleep quickly. I tried pushing some keys and nothing happened on the monitor. I then pressed the power button momentarily to initiate a shutdown. After a couple of seconds, the monitor came on and showed the graphical X desktop display shutting down.
To me this proves that the HDMI can still be activated by the OS even if booted without a connection. I'm not sure what it takes to do that since I didn't spend any time really looking into it. It stands to reason that if Mythbuntu can do it then OpenELEC can do it as well. I will say that I'm not running the 44 BIOS, I'm using the version 43. It is my understanding that the NUC won't even boot without something connected to one of the display outputs with version 44.
EDIT: This information may help as well:
I honestly believe that you can solve this problem without need for a BIOS option. You just need to force X to use that port.
EDIT2: On my OpenELEC flash card for my NUC5PPYH, the kernel boot arguments (APPEND line) are in /flash/syslinux.cfg. I haven't tried forcing the HDMI there, but the appropriate device is card0-HDMI-A-2 for the HDMI output jack. The kernel seems to think that there is also a card0-HDMI-A-1 device.
If I can find the time, I'll do some more testing and see if I can figure this all out. We might need to create an Xorg.conf file to help force the output to the HDMI connector when nothing is connected to it.
This could be a workaround for the HDMI handshake.
The other recommendation would be to post the question in Openelec's forums.