On Tue, 2013-11-19 at 10:48 +0200, Luiz Augusto von Dentz wrote: > Hi Tanu, > > On Tue, Nov 19, 2013 at 9:37 AM, Tanu Kaskinen > <tanu.kaskinen at linux.intel.com> wrote: > > On Mon, 2013-11-18 at 16:51 +0200, Luiz Augusto von Dentz wrote: > >> Im having a hard time to understand why any policy would prefer a > >> profile that is less likely to work than another, > > > > If you have a "bad" (not very well suited for the use case) profile and > > a "good" (very well suited for the use case) profile, and the > > probability of the "bad" profile working is 100% and the probability of > > the "good" profile working is 99%, do you really see no reason to choose > > the "good" profile? > > Well there is nothing to classify a profile as good/bad, is there? Sure there is. The priority value is one (crude) way to rank profiles on a good/bad scale. > Also the chance can be 99% or 1%, so it is not deterministic. My > argument is that pa_card_new don't have this information so it should > not pretend it knows best and select a profile with available set to > unknown. Yes, it's not deterministic, so pa_card_new() shouldn't pretend that it knows that a profile with "unknown" availability is likely to fail. > >> but perhaps we are > >> not willing the mess with other parts of the code that were using this > >> information in a different way. But then why we are bothering > >> selecting any profile on pa_card_new? This is a policy decision and it > >> seems we are not able to do a generic one so it should not even try, > >> pick the first and be done with it. > > > > Yes, it's a policy decision. I would prefer pa_card_new() to always > > choose the "off" profile by default, but that would require work in > > policy modules to keep old use cases working. For example, on the first > > boot of a PC something else than "off" should be selected for the sound > > card, and currently we don't have any policy module that would ensure > > that. > > And nothing fits the "good" profile that works 99% of the time? I > guess that should be marked as available 'yes', or perhaps the modules > should prefer something when they create the card with > pa_card_new_data_set_profile but then we perhaps need to change when > PA_CORE_HOOK_CARD_NEW is fired otherwise it might break things like > module-card-restore. > > >> Anyway if pa_card_new do not select 'off' by default it pretty much > >> breaks Bluetooth qualification and if I change the priority of 'off' > >> profile to force it to be selected it breaks module-bluetooth-policy. > > > > Can you tell the Bluetooth qualification requirement that is failing? If > > it's something HFGW specific, you should be able to implement the > > desired policy in module-bluetooth-policy, without modifying > > pa_card_new(). > > The qualification requires that no audio connection should be open in > certain tests, but right now pa_card_new will select 'hfgw' as it has > the highest priority thus creating a SCO connection. > module-bluetooth-policy doesn't use PA_CORE_HOOK_CARD_NEW perhaps you > want it to use it to select it to 'off' before that. Yes, module-bluetooth-policy should do exactly that, if the default code in pa_card_new() does the wrong thing. > Still this will > only work for modules-bluetooth-policy and internal modules, external > policy components are at the mercy of pa_card_new auto selecting the > right profile. External policy components don't have to be at the mercy of pa_card_new(). If you control the PulseAudio configuration, and pa_card_new() doesn't do what you want, you can load a policy module that does what you want. (And if you don't control the PulseAudio configuration, then external policy components are anyway at the mercy of whatever the policy configuration happens to be.) That said, I see a couple of acceptable ways of making pa_card_new() choose the "off" profile, so you can keep being at the mercy pa_card_new() if you want: 1) Set the priority of the "off" profile above "hfgw". You said that this breaks module-bluetooth-policy. I don't know how it breaks, but there's probably some way of modifying module-bluetooth-policy so that it doesn't break. 2) Change pa_card_new() so that it always defaults to "off". This requires that you write some new policy module that selects a better default profile in PC use cases without any user intervention. -- Tanu
