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
