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).
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
