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

[Mikel Astiz]

Hi Tanu,

On Mon, Nov 26, 2012 at 2:52 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> 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).

Actually this kind of information is missing in the bluetooth-util
library. Have a look at how module-bluetooth-device is directly
handling the property changes in filter_cb(). This can be improved of
course (patches coming soon) but I doubt it's worth addressing this
minor detail for 3.0.

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

Yes, that could be a possible workaround. Afaik headsets would rarely
resume the audio for a specific profile, at least in desktop
use-cases.

As you say, we could disable the policy based on the profile to avoid
messing up with headsets, but doesn't this raise the question whether
module-bluetooth-policy should be loaded at all? I don't think the
average user will be doing both gateway and headset roles.

Cheers,
Mikel