[pulseaudio-discuss] [PATCH v2 0/3] Bluetooth: Late UUID support

[Mikel Astiz]

Hi Tanu,

On Fri, Nov 9, 2012 at 8:00 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> On Sun, 2012-11-04 at 18:47 +0100, Mikel Astiz wrote:
>> Hi,
>>
>> On Fri, Oct 26, 2012 at 8:23 AM, Mikel Astiz <mikel.astiz.oss at gmail.com> wrote:
>> > From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>> >
>> > v2 simplifies patch v1 3/6 (now patch v2 1/3) as proposed by Tanu:
>> > - Use assertion instead of returning error in case of duplicated profiles.
>> > - Avoid lookup to detect card-profile relation, using the new member pointer added in commit 43454bc48c5afee29a2b0c19e6fb80f9bd98ad58.
>> >
>> > The last two patches haven't been modified.
>> >
>> > From original cover-letter:
>> >
>> > PulseAudio does not currently support creating card profiles dynamically. This patchset proposes such feature in order to be used by the Bluetooth modules.
>> >
>> > Mikel Astiz (3):
>> >   dbus: Support dynamically created card profiles
>> >   dbus: Add signal org.PulseAudio.Core1.Card.NewProfile
>> >   bluetooth: Handle UUIDs announced later
>> >
>> >  src/modules/bluetooth/module-bluetooth-device.c | 39 +++++++++++++++++++++++++
>> >  src/modules/dbus/iface-card.c                   | 38 ++++++++++++++++++++++++
>> >  2 files changed, 77 insertions(+)
>> >
>> > --
>> > 1.7.11.7
>> >
>>
>> Any feedback regarding these patches?
>
> Yes, they look good :) I have applied them in a private tree. Does it
> cause trouble for you if I push the patches only after 3.0 is out?

These patches fix a somewhat important issue with newly paired
devices, but apparently nobody complained so far so I agree that it
would be better to leave them out for 3.0.

In fact, it would be good to think about other alternatives, which we
briefly discussed about in the past:
(a) Using separate cards per Bluetooth profile.
(b) Using a single card and a single card profile, and then using the
suspend state of the sink-sources to control the Bluetooth state.

For practical reasons, I could try to implement (b) as RFC and see how
far we can get. We would avoid extending the core with dynamic card
profiles, and additionally it would support doing simultaneous
HFP+A2DP, which some users seem to be interested in.

Cheers,
Mikel