On 21 April 2016 at 12:49, Tanu Kaskinen <tanuk at iki.fi> wrote: > On Thu, 2016-04-21 at 12:26 +0530, Arun Raghavan wrote: >> On 22 March 2016 at 19:11, Tanu Kaskinen <tanuk at iki.fi> wrote: >> > >> > Before a device is unlinked, the unlink hook is fired, and it's >> > possible that a routing module tries to move streams to the unlinked >> > device in that hook, because it doesn't know that the device is being >> > unlinked. Of course, the unlinking is obvious when the code is in an >> > unlink hook callback, but it's possible that some other module does >> > something in the unlink hook that in turn triggers some other hook, >> > and it's this second hook where the routing module may get confused. >> > This patch adds an "unlink_requested" flag that is set before the >> > unlink hook is fired, and moving streams to a device with that flag >> > set is prevented. >> > >> > This patch is motivated by seeing module-device-manager moving a >> > stream to a sink that was being unlinked. It was a complex case where >> > an alsa card was changing its profile, while an echo-cancel sink was >> > connected to the old alsa sink. module-always-sink loaded a null sink >> > in the middle of the profile change, and after a stream had been >> > rescued to the null sink, module-device-manager decided to move it >> > back to the old alsa sink that was being unlinked. That move made no >> > sense, so I came up with this patch. >> > --- >> I think this is a good solution to the problem. Still need to test >> this in a few use cases, but it makes sense to me too. >> >> I also think that it might be nicer to have this be a part of the >> state enum rather than a separate bool. What do you think? I'm okay to >> make that change quickly if you don't want to, fwiw. > > I considered that, but I don't think it's a good idea, because in the > "unlink requested" state the sink is still fully operational, and it > can be running, idle or suspended. Adding a new state would hide the > separation between those states. Fair enough -- I see we do depend on the device state in a few places afterwards. -- Arun
