[pulseaudio-discuss] [RFC PATCH 2/4] switch-on-port-available: Change criteria for keeping the active profile

[João Paulo Rechi Vita]

On Wed, Oct 3, 2018 at 3:22 AM Tanu Kaskinen <tanuk at iki.fi> wrote:
>
> On Tue, 2018-08-07 at 22:00 -0700, João Paulo Rechi Vita wrote:
> > Prefer the active profile only if it has ports with available status YES
> > on the same direction of the port we are trying to switch to and a
> > higher priority than whichever profile we would select to switch to a
> > new port.
>
> I don't really understand this logic. Not all ports with status YES on
> a profile are necessarily active, and I don't see why inactive ports
> should prevent switching away from the current profile.
>

Previously if there was an active port with higher priority than the
port we were trying to switch to and availability YES or UNKNOWN, we
would avoid switching away from the active port to the new port. The
idea is to reduce the preference given to the active port to only when
it has higher priority than the port we were trying to switch to and
availability YES only. The rationale is that since a port with
availability UNKNOWN might not really be available, we shouldn't avoid
the port switching in that case.

> > This patch removes the code that ensures that no profile switching will
> > happen when a new port is available if the currently active port's
> > available state is YES or UNKNOWN, for example when you have the
> > computer permanently plugged to a HDMI device with audio capabilities
> > and plug something on the headphones port.
>
> So you want to switch to the headphones in that case? That's good, but
> what if I have headphones plugged in and I plug in a HDMI monitor that
> I don't want to use for sound? This patch breaks that use case.
>
> I'm not sure what we should do. Maybe add some HDMI specific code, so
> that when HDMI is plugged in, we switch to it only if the HDMI port is
> the card's preferred port (which means that the user has previously
> manually chosen the HDMI output).
>

My idea is that unless a port has been manually selected by the user
at some point in time, it should always follow the priorities defined
in mixer paths files. In both cases you described headphones should
win since the have the higher priority. Notice that the change does
not blindly choose the active profile if it is active and has a YES
port, it simply adds it to the list of profiles that would be
considered, but it still has to have the higher priority by the end of
the loop (which gives a bonus to preferred profile).

So unless I'm missing something or mixing up concepts, despite the
order of connection, if you connect both HDMI and headphones, the
headphones will always be preferred because the have higher priority
(assuming no manual choices were made at any point).

This is consistent with the results I got when testing this, but at
this point is important to say we actually change the ports priorities
downstream to give external devices a higher priority:
https://github.com/endlessm/pulseaudio/commit/40d00e72f74b2177ebead548427debadd6d1c05e.
I believe it should still work the same way for the HDMI+HP case we
are discussing, but I'm now not so sure if we will end up with
Speakers always winning with the upstream priorities. Actually,
probably this commit should have been left for a separate series,
together with the one pointed by the link above. I'll re-organize
things a bit and re-send -- should RFCs continue to be sent to the
list, or should they also be submitted though a gitlab MR?

Thanks for the feedback!

--
João Paulo Rechi Vita
http://about.me/jprvita