[pulseaudio-discuss] RFC: Switch to HDMI or not?

David Henningsson david.henningsson at canonical.com
Wed Feb 3 21:45:09 PST 2016


So, there has been a few bugs related to the new routing, in particular 
[1] which while related to whether or not the actual system has an 
internal speaker or not, also highlights the use case of letting an HDMI 
monitor go to powersave. This will, starting from 8.0, cause sound to be 
rerouted to internal speakers, even after the HDMI monitor comes back 
online.

Here's a recap.

  1) The old situation of playing back audio to an unconnected monitor 
(or powersaved monitor) was not user friendly.

  2) There is no way (AFAIK) we can distinguish between a monitor being 
in powersave mode, or permanently unconnected.

  3) Hence, the proper solution is to switch to analog when the monitor 
is off/powersaved/unconnected and then switch back when it comes back 
online.

  4) The easiest way to do that is, at least after the priority patch 
[2] has been applied, to adjust the port priorities so that HDMI ports 
have a higher priority than analog-speakers. This is also consistent 
with a suggestion from GNOME [3]. However, doing so might instead upset 
people who would like to stay on analog-speakers when their HDMI monitor 
comes back online.

  5) We could then tell those people that they should manually increase 
the priority or analog-speakers in our configuration files, but it could 
be argued that this is not user friendly enough either.

  6) Tanu suggested in [1] to add functionality to remember the latest 
user-selected port and/or profile to module-switch-on-port-available. 
I'm hesitant to that solution, because

  6a) It breaks the main idea of module-switch-on-port-available being 
strictly rule/priority-based, leaving the "remember" feature to the not 
yet finished module-port-manager.

  6b) It seems non-trivial, and I have a gut feeling it will break some 
other use case, that neither of us is thinking about right now.

  6c) I realize neither of 6a) or 6b) are particularly strong arguments 
against actually fixing a problem...

  7) So, this morning I came up with another idea. And this is the RFC 
part of this email. We're not sure whether or not a just 
connected/online monitor has "usable" HDMI audio or not. Hence, maybe 
plugging in a monitor should lead to the HDMI port availability being 
"unknown" rather than "yes"? module-switch-on-port-available will not 
route to something that changes availability from "no" to "unknown".

For this to make sense, we need to add yet another module, which 
determines whether an HDMI port should be "unknown" or "yes" when coming 
back online. If a user manually switches to the HDMI profile then that 
means "yes" from now on, if a user manually switches away then that 
means "unknown" from now on. As a bonus, we could potentially use ELD 
info as a key to a database of "yes" and "unknown" values (this could be 
useful for module-port-manager as well). I'm not sure whether the key 
should be "sink+port", "ELD" or "sink+port+ELD", but probably 
"sink+port+ELD" is the best one considering people with dual monitors. 
What do you think?

  8) Everything said about HDMI applies to DisplayPort as well.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=93946

[2] http://patchwork.freedesktop.org/patch/72053/

[3] https://wiki.gnome.org/Design/SystemSettings/Sound - section 
"Guidelines"

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic


More information about the pulseaudio-discuss mailing list