Hi Pali, On Thu, Jan 24, 2019 at 11:28 AM Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > 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: > > Is is possible to retrieve (from kernel? bluez?) transmission latency? Well that is not a fixed delay, besides PA seems to be already taking some extra latency time into account as it does 2 times some latency I assume that is the hardware which in this case would be the Bluetooth radi. > > 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. > > I think that adding a new function for codec API which calculates codec > latency is the correct way how to deal with it. Yep, indeed we need something to take into account the different algorithm delays. Btw, Ive send a review about the a2dp codec API but apparently it is stuck due to its size, so someone needs to approve it. It is suggesting some changes to the naming, etc, but I think I found a real bug in which the endpoints hash function is used incorrectly since you just pass the endpoint path not the struct pa_a2dp_codec_id. -- Luiz Augusto von Dentz _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
