[pulseaudio-discuss] [PATCH v0 01/11] card: Support adding profiles dynamically

[Mikel Astiz]

Hi David,

On Wed, Oct 24, 2012 at 12:16 PM, David Henningsson
<david.henningsson at canonical.com> wrote:
> On 10/24/2012 11:43 AM, Tanu Kaskinen wrote:
>>
>> On Tue, 2012-10-23 at 10:14 +0200, David Henningsson wrote:
>>>
>>> On 10/23/2012 08:01 AM, Mikel Astiz wrote:
>>>>
>>>> Hi David,
>>>>
>>>> On Mon, Oct 22, 2012 at 6:10 PM, David Henningsson
>>>> <david.henningsson at canonical.com> wrote:
>>>>>
>>>>> On 10/22/2012 10:46 AM, Mikel Astiz wrote:
>>>>>>
>>>>>>
>>>>>> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>>>>>>
>>>>>> Some cards might need to add profiles during their lifetime, that is,
>>>>>> after the card has been created.
>>>>>
>>>>>
>>>>>
>>>>> How are volume control UIs, other modules, etc made aware that the
>>>>> profiles
>>>>> or ports of a card has changed?
>>>>
>>>>
>>>> I believe the D-Bus API as well as the subscription events would have
>>>> to be extended for this purpose, but I haven't addressed either of
>>>> these here. Any thoughts?
>>>
>>>
>>> Just that being able to change a card in ways that was not possible
>>> before, is something that require careful thought. Removal even more so;
>>> what if a volume control UI starts (that was built before we made this
>>> change), and suddenly a profile is removed, and then the user tries to
>>> select this profile?
>>
>>
>> The UI will get an error from pulseaudio. Do you see a problem with
>> that? The UI should be prepared to receive errors from every operation
>> anyway, so it shouldn't crash. It may choose to exit "cleanly" in case
>> of unexpected errors, though, but I'd argue that that's a bad way to
>> handle this kind of errors.
>>
>>> I'm also not sure if there are other parts of the PulseAudio core that
>>> needs to know if things like these change, do you know?
>>
>>
>> I grepped for "profiles" and "ports", and it looked like the only thing
>> needing patching is modules/dbus/iface-card.c, and Mikel provided the
>> necessary patch for that. You might ask whether it was enough to grep
>> for "profiles" and "ports" - I think it was, because if any component is
>> going to maintain data structures that need to be in sync with
>> pa_card.profiles and pa_card.ports, then it will probably at some point
>> reference pa_card.profiles or pa_card.ports...
>>
>>> I'm not opposed to the change, maybe it is inevitable - e g, the
>>> capabilities of HDMI sinks can also change during PulseAudio's life
>>> time, so that's another example of dynamic profiles. What I'm trying to
>>> say here is that:
>>>
>>> 1) This is a quite fundamental change of behaviour, have we thought this
>>> through thoroughly, with all the consequences not only for us but for
>>> our client software as well?
>>
>>
>> I'm pretty confident that this is a safe change (in terms of not
>> breaking well made apps - this may very well expose bugs in apps with
>> not-so-good error handling).
>>
>>> 2) I don't want to release with this being half-done; e g, if we add
>>> profiles without a subscription mechanism and then release, we might end
>>> up with volume control UIs polling us all the time to work around our
>>> own shortcomings.
>>
>>
>> Card change subscription event will be sent.
>>
>> Are you ok with me pushing the patches?
>
>
> Yes, I trust your review. This change might be inevitable sooner or later
> anyway (for HDMI) so why not bring it in now (for Bluetooth).
>
> As for Bluetooth in general, a lot of patches have been coming in during
> this cycle! So I would like to thank the patch authors and reviewers for
> their job!

You're welcome, and also from my side thanks to Tanu for the deep reviews!

> I would also like to ask for a summary of how things have changed, if there
> are any new requirements (e g, a higher bluez version required?), how we all
> benefit from this. And also, if this was the "final big" patchset or if
> there are more coming, i e, if we're halfway through anything, plans for the
> future etc?

I don't have any more patches in the short term, so after the late
UUID I think we are pretty much done. Some minor patches might still
come (i.e. latency tuning for the loaded module-loopbacks) but
otherwise the modules seem quite in a good shape. I have to do even
more testing though, to make sure.

Regarding the future, BlueZ 5.0 will be coming soon and this will have
a big impact in PA. The main benefit would be HFP 1.6, which doesn't
quite fit the current approach. This will probably mean a new module
specific for BlueZ 5.0 and oFono, to be discussed...

Cheers,
Mikel