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

[Tanu Kaskinen]

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?

-- 
Tanu

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.