Skip to content

AE: don't disable devices - as detection does not work reliable #1779

Merged
merged 1 commit into from Dec 12, 2012
@fritsch
Team Kodi member
fritsch commented Nov 13, 2012

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.

@FernetMenta
Team Kodi member

With this patch bad devices will always show up in the selection menu?

@fritsch
Team Kodi member
fritsch commented Nov 14, 2012

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.

@chewitt
chewitt commented Nov 14, 2012

this resolves missing HDMI audio in the OpenELEC AppleTV build, the nVidia card was seen as a bad device and disabled - please commit

@FernetMenta
Team Kodi member

I would prefer an advanced or gui setting which can disable this and maybe other unreliable hw checks.

@elupus
Team Kodi member
@fritsch
Team Kodi member
fritsch commented Nov 14, 2012

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.

@DDDamian

@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.

@jmarshallnz
Team Kodi member

If it's something the user must specify to get sound, then it has to be in the UI.

@fritsch
Team Kodi member
fritsch commented Nov 17, 2012

@DDDamian:
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.

@elupus
Team Kodi member
@jmarshallnz
Team Kodi member

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?

@DDDamian

@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..

@wsnipex
Team Kodi member
wsnipex commented Nov 18, 2012

how about what elupus said, plus a "test audio" button?

@wsnipex
Team Kodi member
wsnipex commented Nov 30, 2012

bump.
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.

@arnova
Team Kodi member
arnova commented Nov 30, 2012

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.

@DDDamian

@grajen was just volunteering in IRC :)

+1 for this though - better a long list and functional audio than a short list without....

@arnova
Team Kodi member
arnova commented Nov 30, 2012

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) ?

@anssih
Team Kodi member
anssih commented Nov 30, 2012

+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)

@FernetMenta
Team Kodi member

I can take the gui part if no one else volunteers.

@pieh
Team Kodi member
pieh commented Nov 30, 2012

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.

@DDDamian

@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.

@MartijnKaijser
Team Kodi member

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).

@DDDamian

Easily done regardless of navsound settings, and has to disregard that setting to be useful...

@fritsch
Team Kodi member
fritsch commented Nov 30, 2012

@pieh:
Thank you very much for jumping in and getting this in a real cool working and improving state, nice :-)

@pieh
Team Kodi member
pieh commented Nov 30, 2012

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 :)

@arnova
Team Kodi member
arnova commented Dec 1, 2012

@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?

@wsnipex
Team Kodi member
wsnipex commented Dec 12, 2012

ping

@anssih anssih merged commit 68dce43 into xbmc:master Dec 12, 2012
@FernetMenta
Team Kodi member

@pieh what about the gui part? IMO it's mandatory to merge this too.

@davilla
davilla commented Dec 13, 2012

do not let this snowball, the clock is ticking. we really should have strings frozen already and adding gui bits means strings.

@FernetMenta
Team Kodi member

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.

@pieh
Team Kodi member
pieh commented Dec 13, 2012

@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)

@FernetMenta
Team Kodi member

@pieh in case you refer to a perfect solution I agree with you. But I don't think this change would break anything:
FernetMenta@9608bdc

It's not perfect but way better than the current state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.