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? 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". 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" - sink2 appears again 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 - sink1 appears again -> sink1 becomes the default sink -> stream moves to sink1, because it was previously routed to the default sink - 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. -- Tanu https://www.patreon.com/tanuk
