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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
