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
