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
