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
