[pulseaudio-discuss] [RFC next v4 12/16] bluetooth: Register HSP/HFP endpoints in BlueZ 5 Media API

[Mikel Astiz]

Hi Tanu,

On Fri, May 10, 2013 at 7:48 AM, Tanu Kaskinen <tanu.kaskinen at intel.com> wrote:
> On Mon, 2013-04-29 at 18:28 +0200, Mikel Astiz wrote:
>> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>>
>> Register the HSP/HFP endpoints in BlueZ 5 Media API for the sake of
>> completeness, despite the fact that there's currently no known user of
>> such an endpoint.
>> ---
>>  src/modules/bluetooth/bluetooth-util.c | 5 -----
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/src/modules/bluetooth/bluetooth-util.c b/src/modules/bluetooth/bluetooth-util.c
>> index e3de01e..e46cbda 100644
>> --- a/src/modules/bluetooth/bluetooth-util.c
>> +++ b/src/modules/bluetooth/bluetooth-util.c
>> @@ -911,11 +911,6 @@ static void register_endpoint(pa_bluetooth_discovery *y, const char *path, const
>>  static void register_adapter_endpoints(pa_bluetooth_discovery *y, const char *path) {
>>      register_endpoint(y, path, A2DP_SOURCE_ENDPOINT, A2DP_SOURCE_UUID);
>>      register_endpoint(y, path, A2DP_SINK_ENDPOINT, A2DP_SINK_UUID);
>> -
>> -    /* For BlueZ 5, only A2DP is registered in the Media API */
>> -    if (y->version >= BLUEZ_VERSION_5)
>> -        return;
>> -
>>      register_endpoint(y, path, HFP_AG_ENDPOINT, HFP_AG_UUID);
>>      register_endpoint(y, path, HFP_HS_ENDPOINT, HFP_HS_UUID);
>>  }
>
> So there was some discussion about whether to do this or not? Could
> someone reiterate the arguments for and against, or point to a relevant
> thread in the mail archive?

The argument in favor of merging these last patches is about feature
completion, as argued in [1]. BlueZ 5's Media API was designed in a
way that an external telephony component could use it and
automatically interact with PulseAudio. In this scenario, BlueZ not
only defines the API but it also acts a component registry, in
particular for org.bluez.MediaEndpoint instances which PulseAudio
implements (to be more precise, the two endpoints for HFP/HSP, which
are now subject of discussion).

oFono was the first telephony component addressing this approach but
in the early stage of implementation, it was decided that this D-Bus
mechanism was not desirable. Instead, a oFono-specific API was
designed to handle the interactions between oFono and PulseAudio (or
other audio components). Therefore, there is no current user of BlueZ
5's MediaEndpoint1 for HFP/HSP, except for old development branches of
oFono.

>
> To me the important question is: if there was a user for these
> endpoints, would the current code in PulseAudio work?

There was a time when this patchset was working with a branch of
oFono, although these patches never made upstream. It's still quite
likely that issues exist and it's always going to be difficult to
maintain a codebase without active users, so I see the point about
leaving this endpoint out until someone actually has real interest in
it.

Cheers,
Mikel

[1] http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-April/017003.html