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

[Tanu Kaskinen]

On Fri, 2016-02-05 at 08:51 +0100, David Henningsson wrote:
> 
> On 2016-02-04 13:54, David Henningsson wrote:
> > 
> > 
> > On 2016-02-04 12:50, Tanu Kaskinen wrote:
> > > On Thu, 2016-02-04 at 11:35 +0100, David Henningsson wrote:
> > > > 
> > > > On 2016-02-04 08:47, Alexander E. Patrakov wrote:
> > > > > 04.02.2016 10:45, David Henningsson пишет:
> > > > > >    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.
> > > 
> > > This same point can equally well be made for David's proposal, though.
> 
> Indeed. I was thinking my risk was lower because it only dealt with 
> HDMI. But maybe that was wrong...
> 
> Anyhow; your proposal involves trying to save the last "user selected" 
> port; how do you determine if a port is user selected or not? (If the 
> port the user wants to select is already set just by selecting profile, 
> then there is no point for the GUI application to call pa_sink_set_port.)

The logic goes as follows (transcribed from code I wrote yesterday)
(this description is just for output ports, but it works the same way
for input ports):

If the profile change was not made by the user, do nothing.

If the profile change didn't affect output, do nothing.

If the number of sinks on the new profile is not 1, unset the preferred
output port. Rationale: if the number is higher than 1, we don't know
which sink the user prefers the most. If the number is 0, the user
doesn't seem to care about output at all.

If the new profile contains sources and they are not the same as with
the old profile, we don't know if the user wanted to activate the new
sink or the new source, so unset the preferred output port.

If we've got this far, we know the user wanted to activate the sink on
the new profile. The user may or may not have wanted to activate the
port that got selected by default for the new sink, but in any case we
set the preferred port to the currently active port. The reason why we
can do this is that the user will surely manually change the port if
she isn't happy with the default, and when the port change occurs, we
update the preferred port at that time.

> > > > > >    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.
> > > > > 
> > > > 
> > > > 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.
> > > 
> > > Here's a plausible use case that will break in a very annoying way with
> > > your proposal and doesn't break with my proposal: let's say that the
> > > user prefers to use headphones when they are plugged in, and the
> > > internal speakers when the headphones are not plugged in, and never the
> > > HDMI output. Now whenever headphones are disconnected, the routing
> > > logic that you propose will choose the HDMI output, because it has
> > > higher priority than the internal speakers. With my proposal the system
> > > remembers that the internal speakers are the preferred output port of
> > > the sound card (which is actually a misrepresentation of the user's
> > > intent, because the user prefers the headphones over the internal
> > > speakers, but luckily that issue is masked by the speakers becoming
> > > unavailable when the headphones are plugged in).
> > 
> > Okay, that makes sense. Scratch my proposal.
> 
> On second thought; what if the module were to, in addition to setting 
> "unknown" instead of "yes", also would set its priority to 1?

I guess you'd also reset the priority to the original value when the
user activates the HDMI profile? I think that would work.

-- 
Tanu