On Sat, 2016-08-20 at 10:28 -0700, James Bottomley wrote: > 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)? To clarify, is the problem that bluez has some arbitrary limitation that it's not possible to connect both HFP and HSP? AFAIK bluetooth doesn't allow two simultaneous audio streams, but I guess that's not the problem here? Would it be possible to fix this in bluez? (I'm not asking you to fix it, I'm just trying to understand the situation - my old understanding was that bluez would support connecting both profiles.) I'm not sure how bluez advertises the supported profiles to other devices, but if bluez doesn't advertise e.g. HSP support unless pulseaudio has first registered the profile, then I don't think option 2 is viable. Also, pulseaudio doesn't manage when profiles are connected or disconnected, and starting to do that (and potentially stomping on other components' toes) doesn't sound like a good idea. An option for disabling HFP seems much more feasible. -- Tanu
