[pulseaudio-discuss] [PATCH v2 4/8] core: move sink-inputs conditionally when update default_sink

[Georg Chini]

On 12.07.19 13:13, Tanu Kaskinen wrote:
> On Wed, 2019-07-10 at 22:03 +0200, Georg Chini wrote:
>> On 10.07.19 16:03, Tanu Kaskinen wrote:
>>> On Fri, 2019-07-05 at 10:57 +0200, Georg Chini wrote:
>>>> On 05.07.19 09:41, Tanu Kaskinen wrote:
>>>>> On Tue, 2019-07-02 at 09:08 +0200, Georg Chini wrote:
>>>>>> On 02.07.19 08:43, Tanu Kaskinen wrote:
>>>>>>> On Mon, 2019-07-01 at 08:03 +0200, Georg Chini wrote:
>>>>>>>> On 01.07.19 07:08, Tanu Kaskinen wrote:
>>>>>>>> When a new sink appears, pa_core_update_default_sink() is called. Since
>>>>>>>> PulseAudio 11.1, bluetooth and USB sinks have higher priority than the
>>>>>>>> internal sound card, so pa_core_update_default_sink() will switch to
>>>>>>>> the BT speakers in your example. The main benefit of module-switch-on-
>>>>>>>> connect was that it moved existing streams to the new sink, but after
>>>>>>>> this patch set that's handled by the core. Therefore there's much less
>>>>>>>> need for module-switch-on-connect.
>>>>>>>>
>>>>>> This is true, but only relevant if there is no configured default
>>>>>> sink. If the configured default sink is set, there will be no switch
>>>>>> to a newly appearing sink because the configured default sink
>>>>>> is prioritized over all other sinks. In this case you still need
>>>>>> module-switch-on-connect.
>>>>> My estimation is that this is very rarely a problem.
>>>> Mh, my estimation is, that this will be the normal case. At some
>>>> point the user will set a default sink manually, and from that point
>>>> on, automatic switching will no longer work. The configured default
>>>> sink is never unset once it is set.
>>> Yes, sure, but I tried to explain why this is rarely a problem. (In
>>> another thread you described a valid use case where this becomes a
>>> problem, but I don't think that's a "normal case".)
>>>
>>>>> If you have manually selected an external sound card as the default
>>>>> sink and you then plug in another external sound card, then you may or
>>>>> may not want to automatically switch to the new sound card. If you
>>>>> fiddle a lot with two external sound cards and you always want to use
>>>>> the last one plugged in, then module-switch-on-connect is still useful,
>>>>> but in this case it doesn't really matter that your old default device
>>>>> choice is forgotten, because PulseAudio will anyway prefer the
>>>>> remaining external sound card.
>>>> This topic is not about forgetting the last sink, but about switching
>>>> to a new sink at all. Once you manually set the default sink, it will
>>>> never switch automatically without module-switch-on-connect,
>>>> because the default sink selection process prefers the configured
>>>> default sink over all other sinks.
>>> You're assuming that we always want to switch to a newly plugged in
>>> device. Let's say that you have just one USB device, no other external
>>> devices. If you for some reason set the internal sound card as the
>>> default device, I think it's a good thing that we don't automatically
>>> switch to that USB device when it's plugged in again. Therefore I think
>>> it's a good thing that we don't load module-switch-on-connect by
>>> default.
>>>
>>> If you in this situation plug in another external device, it would
>>> probably make sense to switch to it, but I don't what the full policy
>>> would look like that would allow this without breaking anything. I
>>> believe it's a good compromise to stick to the current configured
>>> default sink until the user changes it or the device goes away.
>>>
>> You said you will write another mail tomorrow, so I skip most
>> of your comments, but while reading your mails I realized
>> what is really behind my dislike of the current switching logic:
>>
>> I believe it is a bad idea to make switching to new sinks
>> dependent on the configured default sink. Switching to
>> new sinks is something a user should be able to turn on
>> and off separately. Behavior could be something like that:
>>
>> If switching to new sinks is turned off and a new sink turns up,
>> we should never switch to it, even if it has higher priority and
>> even if the configured default sink is not set. The only exception
>> would be if the configured default sink is set and the sink that
>> turns up is the configured default sink.
>>
>> If switching to new sinks is turned on, we always switch to a
>> new device. The configured default sink is the one we always
>> return to when the last added device is removed. This means
>> if two devices have been added, we would already go back to
>> the configured default when the second device is removed. If
>> no default is configured, we would use the highest priority sink
>> to return to.
> As I said in IRC, I changed my mind about always switching to new
> devices regardless of the current configured default sink. I now think
> that's a good idea. As you've said, if the user ever configures the
> default sink, PulseAudio will from then on never switch to plugged in
> devices. I first thought that's OK, because we should respect the
> user's explicit preference if the configured default device remains
> available, and if it isn't available, then automatic switching to the
> plugged in device will work fine.
>
> But if we implement default device history as I've suggested, and the
> internal sound card has ever been configured as the default and is
> therefore in the history database, it will always be preferred over
> never-before-seen plugged in devices, which is bad. In this situation
> automatic switching truly is entirely disabled, without the user
> requesting such policy change and without a way to re-enable the
> policy.

I still can't see much benefit of a default sink history. Why would
I care if I had some USB device or my friend's Bluetooth speakers
made default at some time? It may never be connected again.
And if you have a history, how would you prioritize it? Simply by
time? If yes, would you then allow for multiple occurrences of
the same sink? A one-shot history for a temporary override is
necessary so that the configured default sink does not get lost,
but everything more is in my opinion luxury (though I would not
mind if somebody implemented that).

Which brings me back to the patch set where this discussion
originated. I guess you still want that module-switch-on-connect
uses pa_core_set_configured_default_sink()? Because that
was my original complaint.

>
> You suggested above that if automatic switching to plugged in devices
> is disabled, we shouldn't switch even if there's no configured default
> sink. That has the problem that if you plug in a USB device but keep
> using the internal sound card, PulseAudio will change the routing after
> reboot, because PulseAudio has to choose some sink as the default sink,
> and it will choose the USB sink, because it has higher priority.

That's why I said the exception is, if you have a configured
default sink, it will switch to it. The configured default sink
is exactly for those situations where you want a specific
sink even if higher priority sinks may be available.

If the user chooses not to configure the default sink and not
to use switching, the user will get what was configured, which
is not changing the sink when something is plugged but using
the highest priority sink as default after a reboot.

So I can't see what is bad about your case above.

Apart from that, there is module-default-device-restore, which
could save the current default sink together with the configured
default sink and restore the previous default sink, if the configured
default sink is not set or not available after a reboot.

> Changing the default sink on reboot seems bad enough that we should
> keep switching to higher priority sinks even if automatic switching to
> new devices is otherwise disabled.

 From my perspective it either it can be disabled or it can't. I do not
understand what you mean with "automatic switching is otherwise
disabled" in that context. Only switching to lower priority sinks is
disabled? That does not make much sense to me. I think when
switching is disabled it should mean we only switch to the configured
default sink.

If we now always switch to new devices (how do we do that without
overwriting the configured default sink each time?), I think we need
a way to disable it. As you said yourself, there are many setups where
switching is not wanted. Let me take a laptop as example. You will
probably want that it switches from the internal card to the sound
card of the docking station when you connect it. But you don't
want that it switches to some (higher priority) USB headset that
you plug in only to make a phone call.
So you could set your configured default sink to the docking
station and otherwise disable switching. Together with the
modification of module-default-device-restore you would have
a reliable setup where the USB head set will only become the
default sink if you remove the machine from the docking station
while the head set is connected (regardless if the system is on
or off at the time of removal).

The use case with switching would be the one I described in
another mail, where you permanently have an USB head set
connected but will not want it to become default.

One of my major concerns with coupling switching and the
configured default sink is that users will not understand the
consequences of clicking the little green tick-mark in pavucontrol.
Instead, they will just wonder why switching sometimes works and
sometimes not. From a user perspective I do not see any
obvious connection between setting the sink I normally want
to use and the ability to switch to another device automatically.

Probably all routing schemes have their benefits and drawbacks,
but what I outlined above is at least easy to understand and works
in many different situations.

>
> I don't know if you have some plans to enable module-switch-on-connect
> (or similar policy) by default, but if you do, note the following
> complications:
>
>   * We should only switch to newly plugged in hardware, not to new
> virtual sinks or sinks that are created as part of a profile change.
> I'm not sure about network sinks (tunnels, raop). At least if the
> network sinks are created via automatic discovery, they shouldn't be
> automatically switched to. Also, we shouldn't switch to HDMI
> automatically.
>
>   * We should treat plugging in headphones to an internal sound card the
> same way as plugging in USB headphones. That is, we should make the
> internal sound card the default sink. This can perhaps be implemented
> later, though (or even earlier, by modifying module-switch-on-connect
> without loading it by default).
>
I do not have any plans concerning module-switch-on-connect.
In my opinion it would be better to move the functionality to the
core and have an option in daemon.conf to enable/disable
switching. Having half of the logic in the core and the other half
in module-switch-on-connect seems wrong. But I have enough
patches pending, so I think it does not make sense to add even
more infrastructure changes to the list, especially as it seems
we cannot really agree on the best approach. Actually I would like
to hear more opinions on that matter because the topic allows
multiple solutions and we should implement what most people
find logical and useful.