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

[João Paulo Rechi Vita]

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