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. > > Well, my proposal was slightly different from yours. While you > want to set the routing choice on any stream not playing on the > default sink, I wanted to set it on any stream that is forcefully > moved to the default sink. > With regard to routing, the end result however is the same in > both cases. The only difference is that the streams on the > non-default sinks also have the users choice set, which makes > things easier when it comes to saving/restoring. > So I am fine with your proposal. > > One addition: When the user manually sets the default sink, > the users choice should be reset for the streams currently > playing on the new default sink. I agree. > 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. > > 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. -- Tanu https://www.patreon.com/tanuk
