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

[Tanu Kaskinen]

On Sat, 2016-08-20 at 11:18 -0700, James Bottomley wrote:
> On Sat, 2016-08-20 at 21:03 +0300, Tanu Kaskinen wrote:
> > 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?
> 
> No, the problem is establishing the rfcomm link.  I *think* it's
> actually an intrinsic limitation of the device.

Mmh... I should spend some time with the bluetooth specs to get a
better understanding of this stuff. Rfcomm gets mentioned often, but I
don't really have any idea what it is beyond "some kind of
communication channel".

> >  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 get a connection refused error directly from the device when I try to
> establish a HSP rfcomm link after establishing a HFP one, so I don't
> think bluez can work around this (except by managing the switching, I
> suppose, which would be complex).

In my world, profiles can be "connected" or "disconnected". Is
"connected without rfcomm link" a valid thing?

> > 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.
> 
> Discovery gives us all the supported uuids and we then decide which
> ones to register profiles for, so we know as soon as the device is
> plugged in all the uuids for the profiles it supports.

I meant advertising the local capabilities to remote devices. A laptop
with bluez and pulseaudio installed should advertise audio support to
other bluetooth devices, but I'd guess that won't happen if pulseaudio
doesn't register the audio profiles first.

> > 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.
> 
> Yes, that's more my worry.
> 
> > An option for disabling HFP seems much more feasible.
> 
> OK, I'll code up option 1.

Ok, sounds good.

-- 
Tanu