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

[David Henningsson]

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!
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?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic