[pulseaudio-discuss] [PATCH v0 3/5] bluetooth: Do not switch to profile unless Playing

[Mikel Astiz]

Hi Luiz,

On Wed, Aug 1, 2012 at 3:44 PM, Luiz Augusto von Dentz
<luiz.dentz at gmail.com> wrote:
> Hi Tanu, Mikel,
>
> On Mon, Jul 30, 2012 at 11:20 AM, Mikel Astiz <mikel.astiz.oss at gmail.com> wrote
>> On Sat, Jul 28, 2012 at 4:12 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
>>> On Thu, 2012-07-26 at 12:20 +0200, Mikel Astiz wrote:
>>>> Currently (and IMO incorrectly) module-bluetooth-device and
>>>> module-bluetooth-discover include some policies to handle the initial
>>>> state and the transitions. This needs to be revisited though: my
>>>> proposal would be to move all policies outside these modules (so no
>>>> automatic profile switching), and use the port availability flags to
>>>> expose which streams are playing (and thus the profile should probably
>>>> be switched accordingly, but from some other policy module).
>>>
>>> If the receiving end can initiate the A2DP streaming, then it would seem
>>> logical to mark the port available even if the stream is not currently
>>> playing.
>>
>> Why would this be better than marking it unavailable? Still the
>> profile could be switched in case the user wanted to, forcing the
>> stream to be started. I really wonder if there is any use-case that
>> requires it one way or the other.
>>
>> It doesn't seem to make a big difference for A2DP, but it is
>> definitely relevant for hfgw profile. Only in very rare cases would PA
>> (the HF part) initiate the SCO connection. In most of the cases, a
>> policy module would switch to hfgw profile after the SCO link is up
>> (audio streaming).
>>
>> So, for consistency, it sounds a good idea to treat both HFP and A2DP
>> similarly, unless there are good reasons not to do so.
>
> As for what the patch is doing I don't think it really help us much,
> the policy indeed should not be in device module, but it should load
> the card with profile 'off' so the user, restore module or the policy
> module select the preferable profile once it detects the card was
> loaded properly. In case of being switched by the policy it should
> probably pass '?' so we avoid the race condition where for some reason
> the phone has disconnected SCO while we were attempting to acquire it,
> in the same way the policy can release the SCO connection by setting
> the profile to 'off'.

Please keep in mind that there is a v2 version of the patchset, where
this patch has been split in two patches (HFP vs A2DP). The HFP part
does make a big difference, as described in the cover letter. I doubt
someone can do HFP without this patch.

But yes, you are right, the solution proposed here would never be the
final solution, since the policies should be left outside these
modules.

However we still need to agree on how the Bluetooth states will be
mapped to PA, in particular how card profiles are used and how port
availability could help.

Cheers,
Mikel