[pulseaudio-discuss] [PATCH 2/7] don't move streams to devices that are going away

[Arun Raghavan]

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