[pulseaudio-discuss] [PATCH v0] bluetooth: Merge headset ports into one

[Tanu Kaskinen]

On Sun, 2012-11-25 at 12:28 +0100, Mikel Astiz wrote:
> Hi Tanu,
> 
> On Fri, Nov 23, 2012 at 8:26 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > On Fri, 2012-11-23 at 13:41 +0100, Mikel Astiz wrote:
> >> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
> >>
> >> Merge the former "hsp-output" and "a2dp-output" ports into one single
> >> port, in order to fix the regression of having several independent
> >> entries in the UI.
> >
> > I'm not sure if this is anything serious, but with this change, I think
> > (I haven't actually tested) module-bluetooth-policy works with headsets
> > that support both profiles as follows, not very smartly:
> >
> >  - It never does anything until both profiles enter the "playing" state.
> 
> That was not the intention. The patch should set the port to
> PORT_AVAILABLE_YES if *any* of the two profiles is set, and thus the
> port switch could be triggered.

Ah, so it seems, my mistake.

> > I'm not sure if this scenario is possible. Can headsets initiate the
> > "playing" state for one profile while the other profile is already
> > "playing" too?
> 
> It's very unlikely, I haven't seen that yet.
> 
> >
> >  - If both profiles enter the "playing" state, then semi-randomly one or
> > the other will be activated.
> 
> As stated above, this will happen if any of the two profiles starts
> playing *and* the active profile is "off". But you're right, the
> activated profile will be semi-random, i.e. the policy is not very
> smart.
> 
> I can't think of any workaround to this problem once the ports get
> merged, since module-bluetooth-policy is not able to distinguish the
> state of each Bluetooth profile.

module-bluetooth-policy has all information it needs available from
bluetooth-util, doesn't it? It doesn't necessarily need to even care
about the port availability, it could just directly follow the profile
state (connected/playing).

Am I right that the profile switching logic isn't meant for headsets
anyway? The use case for which the code was written was enabling
hfgw/a2dp_source when those profiles entered the "playing" state without
pulseaudio initiating that state change, or do I remember wrong? Maybe
module-bluetooth-policy could just check that is the port that became
available hfgw or a2dp_source, that way there would be no risk of
messing up headset use cases.

-- 
Tanu