On Thursday 24 January 2019 16:12:23 Luiz Augusto von Dentz wrote: > 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. But does kernel/bluez provides something? > > > 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 In next round try to remove chunks of patches which you have not commented. This should decrease size of email. > 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. I do not think this is a bug, but rather slightly complicated structure and probably harder to understand. I though it is obvious, so I have not put there lot of comments. But seems not and some deep look is needed to understand two level hash tables. -- Pali Rohár pali.rohar@xxxxxxxxx _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
