[pulseaudio-discuss] [PATCH v2 2/2] switch-on-port-available: deactivate direction when the no ports are available for that direction

Georg Chini georg at chini.tk
Thu Jan 4 19:54:40 UTC 2018


On 04.01.2018 14:35, Tanu Kaskinen wrote:
> On Thu, 2018-01-04 at 08:52 +0100, Georg Chini wrote:
>> On 03.01.2018 14:51, Tanu Kaskinen wrote:
>>> Your proposal sounds good, if I understand it correctly. I don't think
>>> module-rescue-streams needs or should be involved, however.
>> Don't we still need module-rescue-stream when a non-default HDMI
>> sink is forcefully suspended? Or do you want to move the rescue
>> functionality to the core?
> I didn't think of this case. Moving rescuing to the core would make
> sense to me, but for now I think it's fine to handle this in module-
> rescue-streams. I think the rescue trigger should be a sink becoming
> unavailable rather than suspended, though. If we were to use suspending
> as the trigger, we'd anyway only do the move when the suspend cause is
> PA_SUSPEND_UNAVAILABLE, and I don't see why we shouldn't rescue streams
> that are left on unavailable sinks that are not suspended.
>
I don't understand the argument. module-rescue-stream currently
rescues any stream if the underlying sink becomes unavailable, so
streams that are left on unavailable sinks that are not suspended
are already rescued.

PA_SUSPEND_UNAVAILABLE would only be an additional trigger for
the case that the sink is not removed. Your current patches change
the state of the sink to unavailable without removing it.

I do not want to rely on another module like switch-on-port-available
to remove the sink. I see three possible ways to ensure that the
streams are properly rescued:

- Change your patches so that the sink will be removed instead of suspended.
- Or add PA_SUSPEND_UNAVAILABLE as additional trigger to 
module-rescue-stream.
- Or let the core rescue the streams in the suspend case.



More information about the pulseaudio-discuss mailing list