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

[Alexander E. Patrakov]

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.

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

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.

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

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

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

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

Definitely.

-- 
Alexander E. Patrakov