[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