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
<[email protected]> wrote:
On 10/22/2012 10:46 AM, Mikel Astiz wrote:
From: Mikel Astiz <[email protected]>
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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
