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

[Tanu Kaskinen]

On Sat, 2018-01-06 at 15:55 +0100, Georg Chini wrote:
> 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.

My point was that the routing is different in these two cases, and I
don't think it should be different:

case 1:

 - you move the video player to the BT headset
 - you disconnect the BT headset
 - you restart the video player
 - you connect the BT headset -> the video player stays on the default
device

case 2:

 - you move the video player to the BT headset
 - you disconnect the BT headset
 - you connect the BT headset -> the video player is moved to the
headset

The only difference is that the video player got restarted in case 1,
and I don't think that should have effect on the routing.

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

I'm OK with a CLI command as a temporary solution.

-- 
Tanu

https://liberapay.com/tanuk
https://www.patreon.com/tanuk