[pulseaudio-discuss] [RFC 2/2] bluetooth: Rank profiles based on available flag

[Tanu Kaskinen]

On Mon, 2013-11-18 at 17:06 +0200, Luiz Augusto von Dentz wrote:
> Hi Tanu,
> 
> On Mon, Nov 18, 2013 at 4:32 PM, Tanu Kaskinen
> <tanu.kaskinen at linux.intel.com> wrote:
> > On Mon, 2013-11-18 at 16:20 +0200, Luiz Augusto von Dentz wrote:
> >> Hi Tanu,
> >>
> >> On Mon, Nov 18, 2013 at 9:36 AM, Tanu Kaskinen
> >> <tanu.kaskinen at linux.intel.com> wrote:
> >> > On Tue, 2013-11-12 at 13:02 +0200, Luiz Augusto von Dentz wrote:
> >> >> diff --git a/src/modules/bluetooth/module-bluetooth-policy.c b/src/modules/bluetooth/module-bluetooth-policy.c
> >> >> index 4a90db7..864d10d 100644
> >> >> --- a/src/modules/bluetooth/module-bluetooth-policy.c
> >> >> +++ b/src/modules/bluetooth/module-bluetooth-policy.c
> >> >> @@ -137,21 +137,22 @@ static pa_card_profile *find_best_profile(pa_card *card) {
> >> >>      void *state;
> >> >>      pa_card_profile *profile;
> >> >>      pa_card_profile *result = card->active_profile;
> >> >> -    pa_card_profile *off;
> >> >> -
> >> >> -    pa_assert_se(off = pa_hashmap_get(card->profiles, "off"));
> >> >>
> >> >>      PA_HASHMAP_FOREACH(profile, card->profiles, state) {
> >> >> -        if (profile->available == PA_AVAILABLE_NO || profile == off)
> >> >> +        if (result == profile)
> >> >> +            continue;
> >> >> +
> >> >> +        if (profile->available > result->available) {
> >> >
> >> > "Unknown" is defined as 0 and "no" is defined as 1, so "no" will be
> >> > preferred over "unknown", which is probably not what you intended.
> >>
> >> Now I figure why the checks for available was done in such way, still
> >> there is no point in disregard 'off' profile like the was doing as in
> >> 99% of the time it is the best/most available profile in the
> >> circumstances where find_best_profile is called.
> >
> > I think there is a point in prioritizing "off" below other profiles
> > whose state is unknown. There are three transport states: disconnected,
> > connected and playing. You are saying that when the transport state
> > changes from playing to connected, then we should change the card
> > profile to off. I think this is a very bad idea. Let's say you're
> > playing music to a BT sink. Then you pause the music, the stream gets
> > corked, the sink gets suspended. When the sink suspends, the transport
> > is released and the transport state changes from playing to connected.
> > In your proposal, pausing the music player changes the BT card profile
> > to off, forcing rerouting (or killing) of the music stream.
> 
> Except that this policy is not used in this case, source/phone/desktop
> profiles are not being handled by module-bluetooth-policy. Btw for
> those profiles they should probably be considered available 'yes'
> always if transport state is different than disconnected and they
> normally are switched directly by the user application such as a media
> player that should request A2DP/music stream or dialer/skype that
> request HFP/voice stream.

I don't really care whether a profile availability is set to "yes" or
"unknown" (I think the distinction doesn't make much sense, it exists
only because someone, probably you or Mikel, didn't want to access the
transport states directly from module-bluetooth-policy). So feel free to
do any modifications in that space if you wish (as long as it doesn't
break anything, of course).

I didn't remember that the code that this patch modifies doesn't affect
PC use cases. If you want to switch to the "off" profile when the HFGW
transport state changes from playing to connected, I'm fine with that.

-- 
Tanu