On Friday 25 January 2019 11:04:22 Tanu Kaskinen wrote: > On Wed, 2019-01-23 at 18:52 +0100, Pali Rohár wrote: > > On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote: > > > Hi Pali, > > > On Sat, Jan 19, 2019 at 7:19 PM Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > > > I think that this patch series is now ready for review and testing. All > > > > needed parts are finished. > > > > > > > > The only problem is with asynchronous profile switching as function > > > > pa_card_set_profile() does not support it. All details are in patch > > > > "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs". > > > > > > > > So can you look at this patch series and review it? > > > > > > I tested this today, it seems to work fine with sbc but with > > > faststream there seems to be some problem somewhere as it does seems > > > to consume too much cpu time. Regarding set_profile that is something > > > I think we will need to address otherwise the UI is pretty much > > > useless to switch as it doesn't seems to react well when -EAGAIN is > > > returned, we could perhaps block on SetConfiguration since we do block > > > on Acquire anyway, or you have already tried that? > > > > Yes, I tried it. Pulseaudio blocks communication and therefore it also > > does not receive following DBus requests from bluez and so > > SetConfiguration timeout. > > > > In fact -EAGAIN is just dropped in pulseaudio bluetooth module and > > replaced by -1. I just wanted to "highlight" that part of code, so I > > used -EAGAIN, but it has same meaning as any other non-zero value. > > > > I was thinking about it and we could block this on another layer. > > pa_card_set_profile() is called when application request to change > > profile via PA socket. So extend pa_card_set_profile() API to pass > > callback function which would be called after profile is changed > > asynchronously. And just block user request until callback is called. > > > > Maybe some other people who understand pulseaudio better can help? How > > to implement asynchronous profile switching? > > To me it seems that either pa_card_set_profile() should be made > asynchronous, which would be nice, because it would allow errors to be > reported properly, or the bluetooth code should just initiate the > profile change operation and pretend that the switching always > succeeds. In the latter option, in case of failure the bluetooth code > would switch to the off profile. > > I'm fine with either option. Seems that immediate switch to profile is easier as implementing whole asynchronous operations. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
