[pulseaudio-discuss] [PATCH] bluetooth: separate HSP and HFP

[James Bottomley]

On Fri, 2016-08-19 at 22:33 +0300, Tanu Kaskinen wrote:
> On Thu, 2016-08-18 at 11:14 -0700, James Bottomley wrote:
> > When all headsets supported both HSP and HFP, life was good and we
> > only needed to implement HSP in the native backend.  Unfortunately
> > some headsets have started supporting HFP only.  Unfortuantely, we
> > can't simply switch to HFP only because that might break older HSP
> > only headsets meaning we need to support both HSP and HFP
> > separately.
> > 
> > This patch separates them from a joint profile to being two 
> > separate ones.  The older one retains the headset_head_unit name, 
> > meaning any saved parameters will still select this (keeping us 
> > backward compatible).  It also introduces a new headset_handsfree.
> > 
> > For headsets that support both HSP and HFP, the two profiles will
> > become separately visible and selectable.  This will only matter 
> > once we start adding features to HFP that HSP can't support (like
> > wideband audio).
> > 
> > Signed-off-by: <James.Bottomley at HansenPartnership.com>
> 
> Thanks, this looks pretty neat. It's hard to tell if any changes are
> missing, but the changes that are there look good, although please 
> use spaces for all indenting. One thing that is missing, though, is
> updating module-bluetooth-policy.c. It references "headset_head_unit"
> in one place, and that code should take the new profile into account
> too.

I actually ran into a problem with the approach.  It's not really a
pulseaudio problem per-se, it's a bluetooth/bluez one: bluez can't talk
simultaneously to both HFP and HSP; once you connect to one "headset"
profile at once and the connection to the other will fail.  Right at
the moment pulseaudio connects to each available profile so the audio
switching can be fast.  The problem is that the first connected profile
for devices which support dual HFP/HSP will always be HFP (dictated by
the ordering of the defaults array in bluez:src/profile.c) and the HSP
connection will subsequently fail, so every dual HSP/HFP device would
become HFP only with this patch (i.e. you won't be able to switch to
HSP even if you want to).

There are a couple of ways of fixing this:

   1. Accept the limitation and disable HSP if the device supports both. 
       The drawback would be any device that badly implements HFP but
      works currently with HSP (not sure if such devices exist).  If it
      becomes a problem, HFP could be disabled with an option.
   2. Don't register with bluez until the device is selected.  This means
      all the negotiation and setup has to occur after the PA profile is
      selected which would lead to a noticeable slowdown in audio
      switching.

Is there any preference (1. is certainly easier for me)?

James