https://bugs.freedesktop.org/show_bug.cgi?id=93946
--- Comment #54 from Julien "_FrnchFrgg_" RIVAUD <frnchf...@free.fr> ---
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.
- 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.
The first three patches look OK to me.
Cheers
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug._______________________________________________
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
