On 03.01.2018 14:51, Tanu Kaskinen wrote: > On Sat, 2017-12-30 at 18:08 +0100, Georg Chini wrote: >> On 30.12.2017 16:12, Tanu Kaskinen wrote: >>> On Sat, 2017-12-30 at 14:27 +0100, Georg Chini wrote: >>>> On 30.12.2017 13:55, Tanu Kaskinen wrote: >>>>> On Sat, 2017-12-30 at 13:09 +0100, Georg Chini wrote: >>>>>> On 29.12.2017 21:28, Georg Chini wrote: >>>>>>> On 29.12.2017 13:49, Tanu Kaskinen wrote: >>>>>>>> There's still the problem that once the HDMI sink is available again, >>>>>>>> streams won't be moved there automatically (unless module-switch-on- >>>>>>>> connect is loaded), but I think that's a lesser problem than keeping >>>>>>>> streams connected to a silent sink. >>>>>> Would not using a hook and let module-rescue-stream handle the >>>>>> suspend/unsuspend solve that problem as well? You would then also >>>>>> have to modify the default sink selection to take the suspend state >>>>>> into account. >>>>> What logic would module-rescue-stream use in the unsuspend case? It's >>>>> not obvious to me how it should determine when to move streams to an >>>>> unsuspended sink and which streams to move. >>>> The same logic that module-switch-on-connect applies with the >>>> difference that the unsuspended sink does not become the default >>>> automatically. So if the "normal" default sink selection determines >>>> that the unsuspended sink should be the default, then move the >>>> streams from the current default to the new one, else do nothing. >>> So module-rescue-stream should move all streams from the old default >>> sink to the new default sink? Or are there some exceptions? Can it even >>> ignore the unsuspend event and only care about default sink changes? >> Yes, in theory module-rescue-stream could just care about default >> sink changes in addition to the appearance and disappearance of >> sinks. This would also simplify module-switch-on-connect or make >> it even obsolete. >> The drawback are those cards with flapping jack detection. At the >> moment we can hide this driver or card problem simply by not using >> module-switch-on-port-available. >> Therefore currently I would use the suspend/unsuspend events to >> avoid mixing several unrelated problems. > Good point about faulty jack detection. We shouldn't add too much > automation that can't be disabled when jack detection is broken. > >>> module-switch-on-connect doesn't move streams that have save_sink set >>> on them. I get the impression that you don't want that exception. >>> Instead, if a stream ever becomes routed to the default sink (either by >>> moving to the default sink, or the default sink changing to the >>> stream's sink), then that should make the stream "default-routed". >> In general you are right, I don't want exceptions. See also my >> other mail. You are however also correct that there are some >> situations I did not think about. So exceptions are necessary >> whenever a stream is moved forcefully to the default sink. >> >> To take care of those situations, the save_sink flag should be >> used differently. It should only be set on those streams that >> have forcefully been moved from a non-default-sink to the >> default sink. Two possible ways this can happen: >> >> 1) The stream is moved to the sink: The original sink disappears >> and the stream is rescued to the default sink. >> 2) The sink is moved to the stream: The default sink disappears >> and the default moves to a sink where some streams are >> already playing. >> >> If the default sink is chosen manually, all save_sink flags should >> be reset. >> A manual stream move to some sink would reset the flag. >> >> This way only streams on the default sink could have the save_sink >> flag set which would always clearly indicate if a stream is playing on >> the default sink on purpose. >> >> > 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. 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.) > The moving can be handled automatically by the core. module-stream- > restore doesn't have to be concerned with moving streams any more, it > just needs to save the routing choices in the database and restore them > when new streams appear. module-switch-on-connect doesn't have to move > streams either, it only needs to set the default sink. This sounds perfect and will make the modules much simpler. > > 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.
