[pulseaudio-discuss] [PATCH] todo: Add plans for the bluetooth modules

[João Paulo Rechi Vita]

Hello guys,

On Wed, Jun 26, 2013 at 11:22 AM, João Paulo Rechi Vita <jprvita at gmail.com>
wrote:
> Hello Luiz,
>
> On Wed, Jun 26, 2013 at 6:59 AM, Luiz Augusto von Dentz
> <luiz.dentz at gmail.com> wrote:
>> Hi Joao,
>>
>> On Tue, Jun 25, 2013 at 9:15 PM, <jprvita at gmail.com> wrote:
>>> From: João Paulo Rechi Vita <jprvita at openbossa.org>
>>>
>>> These plans were discussed and agreed upon through IRC on 2013-06-25 by
>>> Arun, João Paulo, Luiz, Mikel and Tanu.
>>> ---
>>> todo | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/todo b/todo
>>> index 653bedc..3dc4df2 100644
>>> --- a/todo
>>> +++ b/todo
>>> @@ -45,3 +45,14 @@ Long term:
>>>
>>> Backends for:
>>> - portaudio (semi-done)
>>> +
>>> +Bluetooth:
>>> +- Separate BlueZ 4 and BlueZ 5 support in two different module sets
>>> + Both of them will be compiled by default but there should be a way for
>>> + distributors to individually select one or the other
>>> +- Support for HFP/HSP in the BlueZ 5 modules should be implemented as
plugins,
>>> + which will be statically linked and selected at compile time
>>> +- Add support for oFono HFP plugin using the infrastructure mentioned
in the
>>> + previous item
>>> +- Add support for BlueZ' HSP plugin (which is under implementation in
BlueZ by
>>> + Mikel Astiz) using the infrastructure mentioned in the previous item
>>> --
>>> 1.7.11.7
>>
>> Thanks for putting it together, some comments:
>>
>> - The plugins selection can be done via module arguments, I suppose it
>> would be BlueZ 5 only, so it doesn't need to be at compile time. I
>> believe this is easier to package maintainers to maintain via
>> default.pa.
>
> How the separation would be implemented in this case? One separate .c
> file for each plugin with the corresponding header file, and all
> plugin headers being included by the core? One clear disadvantage to
> me is that this way we'll increase the binary size with code that will
> never be used, increasing memory consumption and load time. This will
> affect all deployments of PulseAudio, since there will always be only
> one plugin in use and all the others (which can be more than one if
> different API versions start to show up) will be loaded but never
> used.
>
> And for package maintainers it's just a matter of rebuilding with the
> new configure settings. Since having or not having oFono by default in
> the distribution or product is not a choice that is likely to change
> all the time, I don't think this is a big issue. Am I missing
> something else?
>
>> - Johan just pointed out to me that HSP may not be enough because some
>> headsets may no support it anymore, but I guess we should start with
>> that at least is doesn't conflict with anything.
>>
>
> Yes, when we have the HSP plugin in BlueZ and support for that in
> PulseAudio is easy to extend that for HFP as well.
>
> --
> João Paulo Rechi Vita
> http://about.me/jprvita

So it seems I finally have something suitable for upstream integration. The
whole work is a total of 75 patches so far (still missing mSBC support),
which I divided in 3 series to ease integration:

1) fixes: fixes for some trivial problems I found while going through all
the Bluetooth code.

2) bluetooth-refactor: the revert of the previous support for BlueZ 5,
rename of the "bluetooth" portion of the old modules name for "bluez4",
creation of a new modules set for bluez5 supporting A2DP sink and source
roles, and build infrastructure work to provide independent enable/disable
of each modules set. The transport acquire/release works in a way that the
implementation of this operations can be done out of the bluez5 modules
core.

3) bluetooth-headset-profiles: just 2 patches, one adding support for
HSP/HFP profiles in the BlueZ 5 devices driver (both for the head unit role
and for the audio gateway role), and one that simply register endpoints for
these 4 UUIDs with BlueZ. I came to the conclusion that there is no reason
for us to disable these endpoints even when oFono support is enabled, since
the transport backend is chosen when the transport is created in
PulseAudio, what in turn is triggered by the transport being created either
in BlueZ or oFono. And it will never happen in both because is not possible
to have HSP/HFP enabled in both of them due to SCO limitations.

4) bluetooth-hf-audio-agent: support for the HandsfreeAudioAgent API which
is used to talk to implementation of HSP/HFP in oFono. This is done in a
way which an additional transport backed can be implemented and used as a
drop-in replacement for this support. To add a backend for the Foo service
one has only to write a hfaudioagent-foo.c file which implements the
hfaudioagent.h interfaces and provides acquire and release operations to
the pa_bluetooth_transport_new() call and configure the build with
--with-bluetooth-headset-backend=foo. I not totally in love with this
naming (hfaudioagent.h, hfaudioagent-foo.c and
--with-bluetooth-headset-backend=foo), so suggestions are welcome.

I've done some testing of A2DP source/sink and HFP audio gateway (that is,
routing audio of a phone call to my laptop speakers). Luis promised to do
some more testing next week ;) any other help on this front will be greatly
appreciated.

All this code can be found in my personal repository at
http://cgit.freedesktop.org/~jprvita/pulseaudio/, in the branches with the
same names listed above (fixes, bluetooth-refactor,
bluetooth-headset-profiles, bluetooth-hf-audio-agent), one on top of the
other. 1 is definitely ready for integration and probably 2 as well,
assuming no one finds any problems in there. So I'll send 1 and 2 as patch
series to the mailing list in about half an hour (I'm in the bus heading to
the office atm).

--
João Paulo Rechi Vita
http://about.me/jprvita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20130712/9f2d90fa/attachment-0001.html>