[pulseaudio-discuss] [PATCH 1/3] bluetooth: Do not switch to profile unless Playing

[Tanu Kaskinen]

On Thu, 2011-11-24 at 14:31 +0200, Tanu Kaskinen wrote:
> On Wed, 2011-11-23 at 17:08 +0100, Mikel Astiz wrote:
> > If no audio stream exists to the remote device during discovery, setting
> > the profile to hfgw or a2dp_source would result in a request. This is
> > something that should not be done automatically.
> 
> Earlier in the function there's also a check for "d->audio_source_state
> >= PA_BT_AUDIO_STATE_CONNECTED" (and the same ford->hfgw_state), and if
> that check is true, then module-bluetooth-device will be loaded. The
> only difference that your patch makes is that the "profile" argument is
> not set anymore, so module-bluetooth-device will choose the default
> profile using some other logic. I haven't checked what that other logic
> is, but from the discover module's point of view that doesn't really
> matter, because I don't think it should be aware of
> module-bluetooth-device's internal logic for choosing the default
> profile.
> 
> 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?

Also, now that I started asking questions, what's the role of the
generic Audio interface? Is it ever used alone, or is it so that if the
Audio interface is "connected", does that imply that also at least one
of Headset, AudioSink, AudioSource and HeadsetGateway interfaces are
also "connected"? What if AudioSource is "connected", does it imply that
also Audio is "connected"?

If the Audio interface is useless on its own, then I think
load_module_for_device() shouldn't care about d->audio_state at all. It
should only care about the state of the specific interfaces.

Another question: why does load_module_for_device() ignore
d->audio_sink_state altogether? Is it a bug or feature?

(FYI, I'm working on refactoring load_module_for_device() a bit.)

-- 
Tanu