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

[David Henningsson]

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