[pulseaudio-discuss] [PATCH] bluetooth: Unload the device module when the device becomes disconnected.

[Tanu Kaskinen]

On Mon, 2012-11-19 at 11:52 +0100, Mikel Astiz wrote:
> > Thanks for feedback. So, the module should be unloaded when no audio
> > profiles are connected. Do you see any reason why the checks have to be
> > as complex as they are now in module-bluetooth-discovery: check for
> > "dead", device connected, audio connected and each profile connected? Is
> > the multitude of checks there only to paper over hypothetical bugs in
> > bluez? I mean, it looks like it should be enough to monitor the state of
> > the org.bluez.Audio interface.
> 
> org.bluez.Audio abstracts the headset role only, that's A2DP source
> and HFP/HSP gateway need to be checked additionally.

Ok, that decision seems silly to me, but I guess we just have to live
with it. It would be nice to have that documented in audio-api.txt...

> > If the device is disconnected, surely the
> > Audio state becomes disconnected too? And if none of the individual
> > audio profiles are connected, shouldn't the general Audio state be
> > disconnected too in that case?
> 
> On the other hand, the device's state reflects any Bluetooth profile,
> since it exposes the state of the low level ACL link.
> 
> This means that if Device.State==disconnected, then every other state
> should be disconnected (including Audio.State). So yes, anything else
> would be a bug in BlueZ.
> 
> Note however that the implication is one way only: even if all audio
> profiles get disconnected, the device could still be connected (i.e.
> file being transferred). That was the issue with your patch that I was
> trying to point out.

It looks like Device.State can be ignored, because the individual
profile states, which have to be checked anyway, already sufficiently
describe the device state. I'd ignore Audio.State too, because it
doesn't add any value on top of checking AudioSink.State and
Headset.State individually. (Checking the AudioSink and Headset states
could be replaced by only checking the Audio state, but that would make
the abstraction level inconsistent, if some profiles will still have to
be checked individually.)

I'll prepare an updated patch.

-- 
Tanu