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