Hi Tanu, Thanks for your feedback. > So, my point is that even with your patch module-bluetooth-device may > choose to activate a2dp_source or hfgw, even if their state is just > "connected". I'm not an expert here, so I ask you: should the state > checks be changed also earlier in the function so that > module-bluetooth-device won't get loaded at all if the only connected > profile is a2dp_source of hfgw, and they are not yet in the "playing" > state? The current approach seems to be that module-bluetooth-device will be loaded as long as the device exists and some audio profile is connected, which means the state is connected or playing. In a nutshell, the selected profile represents the interface that is actually playing. Even if a profile is in connected state (not playing), it does make sense to load the module, because then you have the option to change the profile from PA and effectively open an audio stream. This is useful for example in app-initiated audio connections, for example, streaming from phone to PC: the app switches the profile to a2dp_source, and the device simply starts to stream. The problem with this approach is that switching profiles has important side-effects, and must be considered with care. From my point of view, PA should ideally never switch a profile unless it knows it is safe and non app-specific. For this reason, this patch tries to set the initial profile according to the actual streaming state during discovery, but without opening new streams. The patch does not solve the problem entirely since module-card-restore might still switch to a profile, but I was thinking of another patch to fix this second problem. Cheers, Mikel
