On Sat, 2018-01-06 at 15:55 +0100, Georg Chini wrote: > On 04.01.2018 14:27, Tanu Kaskinen wrote: > > On Wed, 2018-01-03 at 17:34 +0100, Georg Chini wrote: > > > On 03.01.2018 14:51, Tanu Kaskinen wrote: > > > > Your proposal sounds good, if I understand it correctly. I don't think > > > > module-rescue-streams needs or should be involved, however. Here's my > > > > proposal: > > > > > > > > - The "save_sink" flag should be replaced with "users_routing_choice", > > > > which is a sink name (i.e. string). > > > > - The routing choice is set when the user moves a stream to a non- > > > > default sink and unset when the user moves a stream to the default > > > > sink. > > > > - When the default sink changes, streams connected to the old default > > > > sink should be moved unless their routing choice is set to the old > > > > default sink. > > > > > > One question: When a stream is created and the sink it is > > > intended to play on is not available, it is put to the default > > > sink instead. Should we keep the users original choice then > > > or remove it because the stream was this time created on > > > the default sink? (I would tend to remove the choice in that > > > case.) > > > > I don't think restarting an application should have effect on how it's > > routed, so I think we should keep the original choice. > > I am not sure if you understood what I mean. Let me make an > example. Consider a stream that is manually moved to some > bluetooth sink, let's say because I want to watch a video using my > bluetooth headset. Next time I watch a video, the BT headset is > not connected and the video is played back on the default device. > The BT headset choice will however be remembered as long as > I do not manually move the stream. > If I now (a couple of weeks and many videos later) connect my > headset and watch a video, the stream will automatically move > to the BT headset. I am not sure if this should be the expected > behavior, but I am OK with keeping it that way. My point was that the routing is different in these two cases, and I don't think it should be different: case 1: - you move the video player to the BT headset - you disconnect the BT headset - you restart the video player - you connect the BT headset -> the video player stays on the default device case 2: - you move the video player to the BT headset - you disconnect the BT headset - you connect the BT headset -> the video player is moved to the headset The only difference is that the video player got restarted in case 1, and I don't think that should have effect on the routing. > > > > To deal with broken jack detection, module-udev-detect should first get > > > > an "enable_jack_detection" option that can be set to false to disable > > > > any automatic routing based on jack detection. (I'd like to have finer- > > > > grained control for disabling jack detection for individual ports > > > > eventually, but I prefer to start with a simple all-or-nothing option > > > > to allow quick progress on the automatic routing improvements). > > > > > > > > > > Would that not be a use case for the message subsystem? In addition > > > to the global flag, each port could have a handler, so that you could > > > disable/enable jack detection on a per port basis on the fly. > > > > Yes, if I'm going to work on this, I plan using the message subsystem. > > But if I'm going to work on this, I will first work on improving how > > configuration files are handled, because the choice of disabling jack > > detection for a port should be saved on disk, and I want to use a > > configuration file for that in a particular way that isn't currently > > supported. > > > > Can't we start with a CLI command? I think it is rather important that > we can enable/disable jack detection on a per port basis. I have seen > quite a few reports of flapping ports recently and somehow it seems > a waste to completely disable jack detection because of a single port. > > The configuration will be rather static anyway and if we have a CLI > command, the user can put it in default.pa (at least temporarily > until your configuration file improvements are done). > > If you agree, I would even volunteer to implement the per port control > once you have implemented the other routing changes (and my > messaging patches are pushed). I'm OK with a CLI command as a temporary solution. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk
