https://bugs.freedesktop.org/show_bug.cgi?id=93946
--- Comment #56 from Tanu Kaskinen <ta...@iki.fi> ---
(In reply to Julien "_FrnchFrgg_" RIVAUD from comment #54)
> As for the patch series that were submitted (and especially the 6th which is
> where all heuristics lie):
> - It seems to me rather hand-wavy the way you try to know if the profile
> change was intentional or not, and I worry about false positives.
Surely the way to know if a profile switch was an explicit user request (which
I assume you mean by "intentional") is not hand-wavy? It's trivial to know
whether a profile change was an explicit request - just check the
"save_profile" flag, that's set iff the user requested the profile switch.
Maybe you mean that the way the patch figures out whether the activation of a
port was the user's explicit request is hand-wavy? That logic is more
complicated, but I'm confident myself that the patch doesn't cause false
positives. It would be very interesting to see a counter example.
> - Why not just remember:
> * whether the current profile/sink was switched to automatically by
> switch-on-port-available), and if true
> * the profile/sink that was active prior to the automatic switch ?
>
> Then in profile_good_for_output(), if the profile being checked is the
> previously checked one, accept it (and maybe give it a priority boost since
> IIUC only the good profile with the highest priority is kept). Maybe this
> logic belongs to the caller of profile_good_for_output() to avoid the need
> for an output param for the new priority, or worse to change the priority in
> the profile struct.
>
> This seems far simpler, and less subject to false positives, while solving
> this specific case of intermittent unavailability. That way you don't tread
> into the territory of a real profile manager, and the patch set would be
> accepted more easily.
Blindly switching to the last manually selected profile has the problem that if
the profile has multiple ports, you don't know which of those ports the user
was interested in when he or she switched to that profile. If there are two
unavailable ports in the profile and one of them becomes available, profile
switch should only happen if the newly available port was the one that the user
was previously interested in.
I'm not sure if that problem has any real-world examples, so your approach
might be good enough, but your feedback did not convince me that it would be a
good idea to rewrite my patches.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_______________________________________________
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
