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