[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 10:01 AM, Tanu Kaskinen <tanu.kaskinen at intel.com> wrote:
> On Fri, 2013-05-10 at 09:06 +0200, Mikel Astiz wrote:
>> 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.
>
> Right, I agree that we should avoid code that isn't used, so I will not
> push this patch. Was it so that also the rest of the set is then not
> necessary?

As explained in the cover-letter, the decision involves the last 5
patches, that is, v4 12/16, 13/16, 14/16, 15/16 and 16/16.

Cheers,
Mikel