[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