On Fri, 2019-07-12 at 20:52 +0200, Georg Chini wrote: > 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? I wouldn't allow for multiple occurrences of the same sink. It would be a priority list. Every time a sink is configured as the default, it would become the highest-priority 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). Yes, maintaining the history isn't very important if module-switch-on- connect uses a temporary override instead of setting the configured default sink (which is now fine by me). > 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. Changing how module-switch-on-connect seems off topic for this patch set, so yes, I would prefer to keep using pa_core_set_configured_default_sink() in this patch set. However, introducing a temporary override mechanism in a separate patch set is fine by me. > > 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. You don't think it's bad that rebooting changes the routing even when there's no change in what hardware is available? In my opinion that's very bad behaviour. > 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. That sounds workable. I'm starting to like your idea of not switcing to higher priority sinks when they become available if automatic switching to new devices is disabled. > > 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? Yes, that's what I meant. > 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. I would be fine with that. (In general I don't see much value in having modules that are built and installed unconditionally. Modules are mainly useful for things that have external dependencies that we don't want the core to depend on. But so far we've been very strict in what can go into the core, and I don't know if everybody would like changing the tradition.) > Having half of the logic in the core and the other half > in module-switch-on-connect seems wrong. Yes. On the other hand, forcing policy in the core isn't nice if someone wants to implement a custom policy system (people have been known to do such thing). It could make sense to have a comprehensive default policy implementation in the core, but allow it to be switched out. > 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 pretty much agree with your proposal now. But you're right that writing more and more patches while the old ones are still pending review isn't necessarily a good idea. Spending time on making the review queue shorter rather than longer would be great ;) -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
