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

[Tanu Kaskinen]

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.
> 
> Well, my proposal was slightly different from yours. While you
> want to set the routing choice on any stream not playing on the
> default sink, I wanted to set it on any stream that is forcefully
> moved to the default sink.
> With regard to routing, the end result however is the same in
> both cases. The only difference is that the streams on the
> non-default sinks also have the users choice set, which makes
> things easier when it comes to saving/restoring.
> So I am fine with your proposal.
> 
> One addition: When the user manually sets the default sink,
> the users choice should be reset for the streams currently
> playing on the new default sink.

I agree.

> 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.

> > 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.

-- 
Tanu

https://www.patreon.com/tanuk