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
