[pulseaudio-discuss] [PATCH v2 0/5] Unloading bluetooth device module instances

[Mikel Astiz]

Hi Tanu,

On Tue, Nov 20, 2012 at 3:48 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> Currently, when a bluetooth device is disconnected, pulseaudio doesn't
> unload the device module. The last patch fixes that. The preceding
> patches do some refactoring so that the final patch can be as nice as
> it is.
>
> This patch set seems to have caused a regression: profile restoring
> with module-card-restore doesn't work if the first profile to get
> connected isn't the one that module-card-restore tries to restore,
> then it doesn't work. For example, if HSP gets connected first and
> module-card-restore has A2DP configured in its database, restoring
> the profile will fail because A2DP isn't yet connected. The reason
> why this appeared to work (at least with headsets) in the past is
> probably that the Audio interface used to change its state to
> "connected" only after both HSP and A2DP were connected. I haven't
> done testing to confirm this theory, though.

I agree with you: the regression is because in the case of headsets
Audio.State is reported only after both profiles have been connected
(or more precisely, the connection attempts are finished).

> v3 will probably be needed to resolve the regression, but I'm sending
> these patches anyway to gather feedback about what should be done.
> Probably the Audio interface needs to be taken into use again, but I'd
> prefer to have something better in the long term, because using the
> Audio interface is only a hack that works only with headsets and only
> if bluetoothd always sends the update for the Audio interface only
> after both HSP and A2DP are connected.

I also think that you need the Audio interface back. AFAIK there is no
way to tell if A2DP is going to be connected after HSP, since
Audio.Connect() sequences the connection attempts but doesn't expose
this outside the Audio interface (i.e. A2DP is *not* in connecting
state).

Regarding the other role, there is no such an issue since BlueZ
doesn't abstract them into one Audio interface. In addition, the card
profiles in PA would be typically handled by policy modules, so
starting up with "off" doesn't do too much harm either.

Cheers,
Mikel