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. > > > > > How is module-stream-restore supposed to behave? If a stream becomes > > "default-routed", it would seem appropriate to erase the "manual > > override" from the stream-restore database, but that doesn't work in > > this scenario: > > > > - sink1 is the default sink > > - sink2 is some other sink > > - stream is manually routed to sink2 > > - sink2 disappears and stream moves to sink1 -> stream becomes > > "default-routed" > > The save_sink flag is set on the stream > > > - sink2 appears again > > Module-stream-restore can detect that the stream should be moved > back to sink2 because of the save_sink flag. > > > > > The stream should quite clearly be moved to sink2, but if the routing > > information is removed from the stream-restore database, no move will > > happen. > > > > On the other hand, if the stream-restore database is left alone, that > > doesn't work in this scenario: > > > > - sink1 is the default sink > > - sink2 is some other sink > > - stream is manually routed to sink2 > > - sink1 disappears -> sink2 becomes the default sink > > The stream gets the save_sink flag set. > > > - sink1 appears again -> sink1 becomes the default sink -> stream > > moves to sink1, because it was previously routed to the default sink > > Module-stream-restore can detect that the stream should not be > moved because of the save_sink flag. > > > - stream disappears (maybe because application is restarted) > > - stream appears again, now module-stream-restore will route it to > > sink2 again > > > > So before restarting the application the stream was routed to sink1, > > and after restarting the application the stream is routed to sink2. > > That doesn't make sense. > > > > Maybe save_sink could contain the name of the origin sink instead > of just being a flag, that would make routing easier. 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. 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. 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). -- Tanu https://www.patreon.com/tanuk
