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

Mikel Astiz mikel.astiz.oss at gmail.com
Fri Dec 14 01:58:53 PST 2012


Hi Tanu,

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.

Cheers,
Mikel


More information about the pulseaudio-discuss mailing list