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

[James Bottomley]

On Sat, 2016-08-20 at 21:34 +0300, Tanu Kaskinen wrote:
> 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".

That's really all it is.  It behaves like a serial link and speaks a
weird extension of the modem AT protocol.  Every bluetooth profile has
one and spec requires you establish this link first and then bring up
the rest of the supported stuff for the profile.

However, Marcel would know better.  I'm not really a bluetooth expert,
I just get to play one every time my desktop won't do what I want with
my devices ...

> > >  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?

Not according to any profile specs I've read (although I haven't read
them all).

> > > 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.

So the way I'd do it is to register one PA transport for each profile
we see a uuid for but not register the connection over dbus to the
bluez.org endpoint until the transport is activated.  It's the
registration of the bluez endpoint that triggers bluez to connect to
the bluetooth profile.  This really is contrary to the way it works
today because we expect an idle transport to be able to connect
instantly.

James