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

[Georg Chini]

On 03.01.2018 14:51, Tanu Kaskinen wrote:
> On Sat, 2017-12-30 at 18:08 +0100, Georg Chini wrote:
>> 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.
> Good point about faulty jack detection. We shouldn't add too much
> automation that can't be disabled when jack detection is broken.
>
>>> 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.
>>
>>
> 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?

> Here's my proposal:
>
>   - The "save_sink" flag should be replaced with "users_routing_choice",
> which is a sink name (i.e. string).
>   - The routing choice is set when the user moves a stream to a non-
> default sink and unset when the user moves a stream to the default
> sink.
>   - When the default sink changes, streams connected to the old default
> sink should be moved unless their routing choice is set to the old
> default sink.
>
> The moving can be handled automatically by the core. module-stream-
> restore doesn't have to be concerned with moving streams any more, it
> just needs to save the routing choices in the database and restore them
> when new streams appear. module-switch-on-connect doesn't have to move
> streams either, it only needs to set the default sink.
>