Hi Pali,
On Wed, Jan 23, 2019 at 7:52 PM Pali Rohár <pali.rohar@xxxxxxxxx> 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.
Right there are D-Bus messages when switching the endpoint, though
what we could perhaps do is create the sink suspended like how it is
done in case of oFono, or at least that is how I remembered it.
> 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?
>
> > Another thing I noticed, we should start taking into accound the
> > algorithm delay of each codec instead of adding a fixed delay of 25
> > ms, in fact 25 ms seems wrong even for SBC since it has about 5 ms of
> > delay not 25 ms.
>
> Yes, this is something I wanted to start addressing. aptX has fixed
> delay of 90 samples. Do you have some pointer there can be that delay
> configured? Or where is that fixed delay hardcoded?
It is hardcoded in FIXED_LATENCY_PLAYBACK_A2DP which is added like this:
pa_sink_set_fixed_latency_within_thread(u->sink,
(pa_bluetooth_profile_is_a2dp(u->profile) ?
FIXED_LATENCY_PLAYBACK_A2DP : FIXED_LATENCY_PLAYBACK_SCO) +
pa_bytes_to_usec(u->write_block_size, &u->encoder_sample_spec));
Perhaps that was used to compensate the transmission latency, but that
would be different for SCO and A2DP, but I tried with just 5 ms and it
seems to work pretty well:
I: [lt-pulseaudio] protocol-native.c: Final latency 100.00 ms = 25.01
ms + 2*24.99 ms + 25.01 ms
As oppose to something like 140 ms which the original code produces.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
