Hello guys, On Wed, Jun 26, 2013 at 11:22 AM, João Paulo Rechi Vita <<a href="mailto:jprvita@gmail.com">jprvita@gmail.com</a>> wrote: > Hello Luiz, > > On Wed, Jun 26, 2013 at 6:59 AM, Luiz Augusto von Dentz > <<a href="mailto:luiz.dentz@gmail.com">luiz.dentz@gmail.com</a>> wrote: >> Hi Joao, >> >> On Tue, Jun 25, 2013 at 9:15 PM, <<a href="mailto:jprvita@gmail.com">jprvita@gmail.com</a>> wrote: >>> From: João Paulo Rechi Vita <<a href="mailto:jprvita@openbossa.org">jprvita@openbossa.org</a>> >>> >>> 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 >> <a href="http://default.pa">default.pa</a>. > > 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 > <a href="http://about.me/jprvita">http://about.me/jprvita</a> 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 <a href="http://cgit.freedesktop.org/~jprvita/pulseaudio/">http://cgit.freedesktop.org/~jprvita/pulseaudio/</a>, 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 <a href="http://about.me/jprvita">http://about.me/jprvita</a>