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

Tanu Kaskinen tanuk at iki.fi
Mon Nov 26 06:23:39 PST 2012


On Mon, 2012-11-26 at 15:06 +0100, Mikel Astiz wrote:
> Hi Tanu,
> 
> On Mon, Nov 26, 2012 at 2:52 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > 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.

Fair enough.

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

I think playing music from a phone via bluetooth to a PC is common
enough use case to justify loading module-bluetooth-policy by default.

-- 
Tanu



More information about the pulseaudio-discuss mailing list