[pulseaudio-discuss] Adding support for bluetooth headsets that only have HFP

Submitted by James Bottomley on Aug. 18, 2016, 2:51 p.m.

Details

Message ID 1471531877.2389.22.camel@HansenPartnership.com
State Not Applicable
Headers show
Series "Adding support for bluetooth headsets that only have HFP" ( rev: 1 ) in PulseAudio

Not browsing as part of any series.

Commit Message

James Bottomley Aug. 18, 2016, 2:51 p.m.
I recently switched from a JBL Flip 2 which supports both HSP and HFP
to an Ultimate Ears Boom 2 which is HFP only.  Needless to say this
currently means that the Ultimate Ears fails to work with pulseaudio
because we only support HSP via the native backend.  The first thing to
note is that we can easily get HFP running in pulseaudio via a quick
hack to switch support from HSP to HFP (see patch below) because if you
don't negotiate protocols on HFP it looks pretty much like HSP for the
audio stream.  Unfortunately, doing this would break half the headsets
out there which only support HSP, so the hack is for demo purposes
only.

I think the fix is to expose HFP and HSP separately as different
pulseaudio profiles.  This would also allow negotiating useful HFP
features, like wideband audio, which HSP doesn't support.  It would
also mean that people currently using HSP would continue, even if they
had HFP and that headsets which support both will show both in the PA
configuration possibilities.  If people are OK with this approach, I
can produce a patch set.

James

---

Patch hide | download patch | download mbox

diff --git a/src/modules/bluetooth/backend-native.c b/src/modules/bluetooth/backend-native.c
index 86376c0..33feb98 100644
--- a/src/modules/bluetooth/backend-native.c
+++ b/src/modules/bluetooth/backend-native.c
@@ -438,7 +438,7 @@  static void profile_init(pa_bluetooth_backend *b, pa_bluetooth_profile_t profile
     switch (profile) {
         case PA_BLUETOOTH_PROFILE_HEADSET_HEAD_UNIT:
             object_name = HSP_AG_PROFILE;
-            uuid = PA_BLUETOOTH_UUID_HSP_AG;
+            uuid = PA_BLUETOOTH_UUID_HFP_AG;
             break;
         default:
             pa_assert_not_reached();

Comments

On Thu, 2016-08-18 at 07:51 -0700, James Bottomley wrote:
> I recently switched from a JBL Flip 2 which supports both HSP and HFP
> to an Ultimate Ears Boom 2 which is HFP only.  Needless to say this
> currently means that the Ultimate Ears fails to work with pulseaudio
> because we only support HSP via the native backend.  The first thing to
> note is that we can easily get HFP running in pulseaudio via a quick
> hack to switch support from HSP to HFP (see patch below) because if you
> don't negotiate protocols on HFP it looks pretty much like HSP for the
> audio stream.  Unfortunately, doing this would break half the headsets
> out there which only support HSP, so the hack is for demo purposes
> only.
> 
> I think the fix is to expose HFP and HSP separately as different
> pulseaudio profiles.  This would also allow negotiating useful HFP
> features, like wideband audio, which HSP doesn't support.  It would
> also mean that people currently using HSP would continue, even if they
> had HFP and that headsets which support both will show both in the PA
> configuration possibilities.  If people are OK with this approach, I
> can produce a patch set.

I was under the impression that supporting HFP would have to be much
more complex than that. If that one-line hack really is sufficient for
getting audio moving, I think it makes sense to add HFP support to the
native backend. I see you already went ahead and produced a more
complete patch :) I'll have a look shortly.

-- 
Tanu
On Fri, 2016-08-19 at 20:24 +0300, Tanu Kaskinen wrote:
> On Thu, 2016-08-18 at 07:51 -0700, James Bottomley wrote:
> > I recently switched from a JBL Flip 2 which supports both HSP and
> > HFP
> > to an Ultimate Ears Boom 2 which is HFP only.  Needless to say this
> > currently means that the Ultimate Ears fails to work with 
> > pulseaudio because we only support HSP via the native backend.  The 
> > first thing to note is that we can easily get HFP running in 
> > pulseaudio via a quick hack to switch support from HSP to HFP (see 
> > patch below) because if you don't negotiate protocols on HFP it 
> > looks pretty much like HSP for the audio stream.  Unfortunately, 
> > doing this would break half the headsets out there which only 
> > support HSP, so the hack is for demo purposes only.
> > 
> > I think the fix is to expose HFP and HSP separately as different
> > pulseaudio profiles.  This would also allow negotiating useful HFP
> > features, like wideband audio, which HSP doesn't support.  It would
> > also mean that people currently using HSP would continue, even if 
> > they had HFP and that headsets which support both will show both in 
> > the PA configuration possibilities.  If people are OK with this 
> > approach, I can produce a patch set.
> 
> I was under the impression that supporting HFP would have to be much
> more complex than that. If that one-line hack really is sufficient 
> for getting audio moving, I think it makes sense to add HFP support 
> to the native backend. I see you already went ahead and produced a 
> more complete patch :) I'll have a look shortly.

I still think something has to be done in the negotiation.  The spec
definitely implies there's a mandatory rfcomm negotiation before you
establish audio links.  I think I've found a device that's more
unforgiving with this (the Boom seems fine to establish audio links
with no negotiation), so I'll complete the patch series when I get this
working.

The patch is still more of a demo of "is it OK that the interface
appears like this" than a "this works for all known devices apply it".

James