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

[Luiz Augusto von Dentz]

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.


-- 
Luiz Augusto von Dentz