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

[Tanu Kaskinen]

On Wed, 2018-11-21 at 11:43 -0800, João Paulo Rechi Vita wrote:
> Hello Tanu! Sorry it took me so long to get back on this issue, but I
> was busy with some urgent things lately. Please find my reply in-line
> below.

No problem!

> On Sun, Oct 7, 2018 at 12:46 AM Tanu Kaskinen <tanuk at iki.fi> wrote:
> > On Fri, 2018-10-05 at 18:26 -0700, João Paulo Rechi Vita wrote:
> > > 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.
> > 
> > Yes, the port priorities are not set up as good as they should.
> > Speakers shouldn't be the highest-priority port. That problem is
> > mitigated to a large extent by marking speakers unavailable when
> > headphones or lineout is plugged in, but that's not really ideal.
> > 
> > The priority order of ports should actually depend on whether they have
> > jack detection support or not. Speakers should have higher priority
> > than external ports without jack detection, but lower priority than
> > external ports with jack detection.
> > 
> 
> Is there a way to specify that in the paths files?

No, otherwise this probably would have been fixed already :)

I'm not sure how the fix should be implemented. Maybe the simplest fix
would be to have two priority values for each path. One would be used
when the path has jack detection support and the other when the path
doesn't support jack detection. But perhaps it would be better to not
have very complex policy rules embedded in the path configuration,
because policy decisions don't really belong in the hardware
description.

I'd like to have a lookup table for mapping an output device type to
its priority (and of course another table for input device types).
Currently it's very cumbersome to try to get an overview of how the
different alsa paths relate to each other in terms of priority, and
that's only alsa, trying to figure out how other outputs rank is even
harder. The table that I envision would be generic (not specific to
alsa or any other backend), and as fine-grained as necessary. There
would be entries not only for simple stuff like "headphones",
"speakers" and "hdmi", but distinction would be made between outputs
that support or don't support jack detection, integrated or external
speakers etc., whatever is relevant for building a complete ranking of
all different kinds of outputs that we support (and can distinguish).
The backend (e.g. alsa) would either directly set the device type, or
provide a generic metadata structure that a generic function could use
to map the metadata into the device type identifier (the latter option
seems better, because it probably reduces duplication of work between
the backends, and the metadata could be useful for policy modules).

Making that table reconfigurable by users or policy modules would be
desirable, but the first step would be to just have such table.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk