[pulseaudio-discuss] [PATCH next v0 08/10] bluetooth: Refactor dependency to org.bluez.Audio

[Tanu Kaskinen]

On Fri, 2012-12-14 at 10:58 +0100, Mikel Astiz wrote:
> On Fri, Dec 14, 2012 at 10:24 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > On Wed, 2012-12-12 at 13:17 +0100, Mikel Astiz wrote:
> >> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
> >>
> >> The state of this interface is needed for one single reason: we need to
> >> wait until all profiles have been connected (or more precisely, until
> >> are connection attempts are finished). This can be made more explicit in
> >> the code by just checking the CONNECTING state (and not loading
> >> module-bluetooth-device during that state), but otherwise treating all
> >> transport types equally.
> >>
> >> Ideally, audio_state should be completely removed but it's left there to
> >> avoid an issue with module-card-restore, as documented in the source
> >> code's comments.
> >
> > I remember seeing some discussion recently at #bluez about keeping the
> > device state "connecting" until all profile connection attempts are
> > finished. Is that now the official plan? So it may not be necessary to
> > modify module-card-restore to handle the removal of the org.bluez.Audio
> > interface?
> 
> Actually no, there is no plan to support anything similar to the old
> Audio interface.
> 
> We discussed this several times and the conclusion was that BlueZ
> cannot solve this problem completely: if the connection is initiated
> by the remote device, there is no way org.bluez.Audio or a similar
> interface could tell if all profiles have been connected. So the
> conclusion was that this is something that needs to be handled outside
> BlueZ, in this case inside PulseAudio.
> 
> This conclusion was reached after I asked in #pulseaudio if
> module-card-restore could be modified to handle the case where a card
> is loaded before all profiles get connected (which is the scenario we
> were trying to avoid by using org.bluez.Audio). The feedback was that
> yes, it should be possible, so that's why we decided to keep the 5.0
> API simple.
> 
> If anybody has a counter argument to make such a change in PulseAudio,
> this would be a good moment to state it, before BlueZ 5.0 gets
> released.

At least I don't have a counter argument. The reasoning seems valid to
me.

-- 
Tanu