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

[David Henningsson]

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

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


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic