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

[Georg Chini]

On 04.01.2018 14:27, Tanu Kaskinen wrote:
> On Wed, 2018-01-03 at 17:34 +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. 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.
>>
>> One question: When a stream is created and the sink it is
>> intended to play on is not available, it is put to the default
>> sink instead. Should we keep the users original choice then
>> or remove it because the stream was this time created on
>> the default sink? (I would tend to remove the choice in that
>> case.)
> I don't think restarting an application should have effect on how it's
> routed, so I think we should keep the original choice.

I am not sure if you understood what I mean. Let me make an
example. Consider a stream that is manually moved to some
bluetooth sink, let's say because I want to watch a video using my
bluetooth headset. Next time I watch a video, the BT headset is
not connected and the video is played back on the default device.
The BT headset choice will however be remembered as long as
I do not manually move the stream.
If I now (a couple of weeks and many videos later) connect my
headset and watch a video, the stream will automatically move
to the BT headset. I am not sure if this should be the expected
behavior, but I am OK with keeping it that way.

>
>>> To deal with broken jack detection, module-udev-detect should first get
>>> an "enable_jack_detection" option that can be set to false to disable
>>> any automatic routing based on jack detection. (I'd like to have finer-
>>> grained control for disabling jack detection for individual ports
>>> eventually, but I prefer to start with a simple all-or-nothing option
>>> to allow quick progress on the automatic routing improvements).
>>>
>> Would that not be a use case for the message subsystem? In addition
>> to the global flag, each port could have a handler, so that you could
>> disable/enable jack detection on a per port basis on the fly.
> Yes, if I'm going to work on this, I plan using the message subsystem.
> But if I'm going to work on this, I will first work on improving how
> configuration files are handled, because the choice of disabling jack
> detection for a port should be saved on disk, and I want to use a
> configuration file for that in a particular way that isn't currently
> supported.
>
Can't we start with a CLI command? I think it is rather important that
we can enable/disable jack detection on a per port basis. I have seen
quite a few reports of flapping ports recently and somehow it seems
a waste to completely disable jack detection because of a single port.

The configuration will be rather static anyway and if we have a CLI
command, the user can put it in default.pa (at least temporarily
until your configuration file improvements are done).

If you agree, I would even volunteer to implement the per port control
once you have implemented the other routing changes (and my
messaging patches are pushed).