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
