This fixes at least two problems:
a) The detection goes wrong on some Intel and nvidia devices. Those users end up with non working HDMI Audio. AMD cards were whitelisted since a long time, as they report always disconnected.
b) If a user boots with his (probably faulty) receiver powered off. He cannot reactivate the HDMI output later, as it is only scanned on startup. Many users boot with TV and AVR off, so end up with no audio.
There are probably better solutions to this. It should not introduce regressions, but it should make audio work for users with the described problems.
With this patch bad devices will always show up in the selection menu?
For now, the bad devices detection only somewhat worked for nvidia devices and intel devices. AMD was whitelisted some time ago in: fa81a76 anyways.
I found at least one user for nvidia in #xbmc, that did not get HDMI Audio with nvidia and one openelec user (with pre frodo) where it did not work directly connected to his TV. ELD parsing does not seem to work with all the "broken" hardware out there. Both tried the above patch to make it work.
So to answer your original question: Yes.
this resolves missing HDMI audio in the OpenELEC AppleTV build, the nVidia card was seen as a bad device and disabled - please commit
I would prefer an advanced or gui setting which can disable this and maybe other unreliable hw checks.
I agree, this would be a better solution.
If it was only a advancedsettings.xml solution many users won't be able to make those changes, as editing xml files is not somewhat userfriendly.
If it was a GUI solution: "disable failsafe hw detection" or "enable all audio devices" it would introduce translation work and probably GUI skin changes. Also we have to discuss the position in the settings.
Also we have to consider that there must be a "reload mechanism" that does the device enumeration again to activate closed sinks.
@anssih @DDDamian what do you think is the best solution to this from the AE side?
I remember we discussed an approach that somehow was: "Don't disable a specific device if no other was detected". In this case:
Only disable HDMI if there is a valid spdif connection.
Keep Spdif and HDMI enabled if there was no connection at all.
@fritsch - the list should re-populate any time the Settings>System>Audio Output window is opened, via GUIWindowSettingsCatagory.cpp ln:2876
IMO the only platform affected here is Linux, and there's been many complaints that a user can no longer select Custom devices. Because it seems to be just that platform I'd recommend an as.xml setting to show the full list as well as an as.xml string for a Custom device setting which would take precedence.
If it's something the user must specify to get sound, then it has to be in the UI.
I disagree with the advancedsettings.xml, with the point I mentioned in my second post. I would make it the other way round: By default show all devices, give the possibility to add an advancedsettings.xml entry to not show bad ones.
I also would prefer showing bad devices instead of manually entering a String. If the user needs to write a string into there - this is much more error prone than selecting the devices from a list.
Might be possible to throw up a select dialog instead of the spinner. How long is the list of what XBMC thinks are "valid" devices? Does it make sense to have a spinner for that, then a select for the rest, or is it best just to have a single setting that throws up the select dialog with everything filled in?
@fritsch - trust me I'd love to see more of the audio settings in the GUI for current and future parameters. That said, Elupus' idea seems to cover all the bases..
how about what elupus said, plus a "test audio" button?
if we can't get the suggested fixes for frodo, we should at least merge this as is. better a long list of devices then no audio at all.
Nice to have this fix in yes but since the lists will be quite long on a lot of systems I think having a select dialog (instead of a spinner) is mandatory.
@grajen was just volunteering in IRC :)
+1 for this though - better a long list and functional audio than a short list without....
When using a selection dialog: perhaps we could then also somehow mark the "reliable" devices or seperate them somehow (reliable ones on top, unreliable ones below) ?
+1 for better than nothing. Sorry for having been MIA lately :/
As for arnova's comment, if the dialog shows all the devices at once, the "reliable" HDMI devices have the receiver/TV name in them, which may differentiate them enough? (I'm not opposed to additional marking if wanted)
I can take the gui part if no one else volunteers.
Initial gui work - just poping up dialog to select device instead of spinner: https://github.com/pieh/xbmc/commits/ae_select_device
looks like this: https://dl.dropbox.com/u/28792047/xbmc/screenshot006%20%282%29.png
If needed I can add "test audio" button there, just let me know. Not sure how to mark reliable/unreliable items other than prepending "[unreliable]" (or smth like this) to friendly device name.
@pieh - nice! A test button would be perfect - even if just to trigger a navsound. Code could be added to play a multichannel wav file almost as a speaker test too. It'll get downmixed accordingly anyways, so a 7.1 wav is perfect. The navsounds are IIRC skin-dependent though.
Curious what this would look like on a Linux/ALSA rig.
I disable GUI sounds at first sight of xbmc startup. So it would be very preferable that the test sound would play regardless of gui sound settings (in appearence or audio settings).
Easily done regardless of navsound settings, and has to disregard that setting to be useful...
Thank you very much for jumping in and getting this in a real cool working and improving state, nice :-)
This test button should be located in same dialog as audio devices (in my screenshot) or just in same settings tab? I didn't think much and put it in dialog but now I start to wonder if that even makes sense ...
Anyway, I updated my branch with what I got and it looks like that now https://dl.dropbox.com/u/28792047/xbmc/screenshot007%20%282%29.png . That topmost "ok" dialog is just for testing and should be replaced with real audio testing code :)
@pieh: looking good. I think prefixing with "unreliable" is rather "long" and might be confusing for users? Like I said: Perhaps move those down to the bottom and suffix/prefix with ? or something?
AE: don't disable devices - as detection does not work reliable
@pieh what about the gui part? IMO it's mandatory to merge this too.
do not let this snowball, the clock is ticking. we really should have strings frozen already and adding gui bits means strings.
hmm, this gui bit is a trivial change and I see no reason why ruin the user experience just in favor to be strict on frozen master.
@FernetMenta given that users should set settings once and forget I would rather push gui part after release - who knows what I could break there ... better working "unfriendly" gui than not working one (in worst case scenario)
@pieh in case you refer to a perfect solution I agree with you. But I don't think this change would break anything:
It's not perfect but way better than the current state.