On 2016-02-04 08:47, Alexander E. Patrakov wrote:
04.02.2016 10:45, David Henningsson пишет:
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.
Partially agree. As always with old bugs, there may be people for whom
they are features.
2) There is no way (AFAIK) we can distinguish between a monitor being
in powersave mode, or permanently unconnected.
No opinion here, ask the graphics guys.
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.
Well, here I also don't 100% agree. You are focusing on the "what
happens when the monitor comes back from powersaving mode" side of
things - which is too late and too passive. My opinion, as a user, is:
1. If audio is playing on HDMI (even if this is a music file), it is a
mistake to apply DPMS. Black out the screen if needed for screensaver -
maybe, DPMS - no. Personally, I have disabled DPMS on my desktop PC, but
this is also due to a different bug, unrelated to audio.
2. An attempt to play audio to a DPMSed monitor should try to wake it
up. I understand that we lack an infrastructure to do this. But,
ultimately, only if that fails or times out, audio should be moved to
analog (if moved at all).
I understand that this is better discussed on something like dri-devel,
but I have no concrete-enough proposal to actually present there.
Right, this is a very valid point. We could instead try to fix graphics
driver(s) to make sure
a) monitors appear connected when they are in powersave
b) to not make them go to powersave when an audio stream is currently
playing back
c) to wake them up from powersave when an audio stream is started.
We also do not know (or at least I don't) whether some graphics drivers
already work this way, but the person in the bug seems to use standard
Ivybridge graphics, so that probably means that a fair share of existing
HDMI ports appear disconnected when they are in DPMS.
So, while this seems to be an interesting route forward (especially
given the i915 component framework which can transfer ELD and PD bits
without taking a hardware detour), we still have a problem here and now.
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.
Let's see whether such people exist.
But I have another class of upset people: those whose monitor supports
HDMI audio and has only headphones output, which is unused (but we can't
know that it is unused, i.e. that the monitor is in fact a glorified
null sink). Which is exactly what the proposal at the end of your email
addresses (better accounting of HDMI port availability).
Indeed. In the best of worlds, the HDMI port availability should be the
same as whether those headphones are plugged in or not, but I doubt this
works.
And also the case of two audio-capable monitors. When the graphical
session power-saves them "at the same time", there is a race. Suppose
that the user wants his audio on HDMI2, but there is also HDMI1. So, if
HDMI1 is slower to respond to DPMS, the audio could be rerouted this
way: HDMI2 -> HDMI1 (temporarily) -> analog. When the monitors come back
up: analog -> HDMI2, but then HDMI1 (with a higher priority) comes up.
This is also addressed by your proposal.
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.
It is indeed not user friendly. But we don't have a 100% user-friendly
solution, because mind-reading technology is not quite there yet. So
some user interaction is definitely needed.
We can also debate whether mind-reading technology in itself is user
friendly, but that's hardly on topic here :-)
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.
My opinion (a trivial one, I'd admit) is that any rule/priority-based
zero-configuration logic is busted in at least one case. We definitely
need to take user interaction into account somewhere if we don't want to
require explicit configuration.
Agreed.
There is also problem here with interpreting users intent through the
existing API: that we have default-sink and default-source but not
default-port (-input/ -output), and that there is no API to switch a
profile and port simultaneously.
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.
Based on our past experience here, I agree.
6c) I realize neither of 6a) or 6b) are particularly strong arguments
against actually fixing a problem...
I think here you meant "trying to fix".
I also think the real problem here is to convince others that you have
indeed fixed the original problem :) so for me 6b is strong enough.
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".
Makes sense, given the additional module mentioned below. Is there any
other (non-HDMI) example of a port availability going from "no" to
"unknown"?
Internal speakers toggle between "no" and "unknown" today; i e, when you
unplug your headphones, internal speakers go to "unknown" rather than
"yes". This somewhat indicates that speakers are now available, but you
did not make an active choice to use them.
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?
I am a bit concerned with assigning numbers dynamically for
HDMI/DisplayPort audio pcms. So, given the semi-dynamic proposal that
you made a year ago, I'd say the key should be "sink+port+ELD if dynamic
numbering is not in use, sink+ELD if it is in use".
Actually I think it should be card+ELD and card+port+ELD rather than
sink, as the sink name changes when the profile changes. And we need the
card+port+ELD version to cope with two identical monitors, right?
8) Everything said about HDMI applies to DisplayPort as well.
Definitely.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
