High delay when answering calls with bluetooth headset

[driesken]

Good evening,

1. Describe the bug (mandatory)

I've been experimenting with several bluetooth headsets but I've found the delay on (almost) all incoming calls unworkable (+- 800ms). However, when I'm placing an outgoing call, the delay is very low and remains that way. I don't suppose it's headset related since I've noticed it on different models and when using different codecs like alaw & opus.

2. To Reproduce (mandatory)

The first call in the attached logs is outgoing and has very low latency in the beginning of the call. The second call is incoming and has high delay.

3. Expected behavior (mandatory)

Should expect to be able to answer calls with (almost) same delay as when placing them.

4. Please complete the following information (mandatory)

• Device: Samsung Galaxy S10e (also occurs on Samsung XCover 5)
• OS: Android 12
• Version of the App -> 4.7.0
• Version of the SDK -> SDK 5.2.0-alpha.358+fe511c0 (latest master)
• Where you did got it from -> local build
• stock Android

If you are using a SDK that isn't the latest release, please update first as it's likely your issue is already solved.

5. SDK logs (mandatory) 637bbd37ec339_b526b9ce56ad75d3c623.txt

[Viish]

Hi,

I'm not sure it's related to the BT headset. Does incoming call work as expected when you disconnect it? When it "works":

2022-11-21 19:01:59:656 [uzlinphone.org/mediastreamer] MESSAGE MSAudio_stream_iterate[0x743f71f8d0], local statistics available:
	Local current jitter buffer size:  60.0ms

When it doesn't:

2022-11-21 19:02:25:089 [uzlinphone.org/mediastreamer] MESSAGE MSAudio_stream_iterate[0x743f71f8d0], local statistics available:
	Local current jitter buffer size: 593.6ms

Also there is an issue in the codec negociation for the incoming call, it seems the callers asks for opus/48000 fmtp=maxaveragebitrate=48000;cbr=1;useinbandfec=1 in stereo and linphone doesn't match for some reason: No match for opus/48000/2 causing the call to use G711 (Alaw) audio codec. What is the remote device? Have you tried with another linphone device, and if yes do you have the same issue?

Please use release/5.2 branch of the SDK that is way ahead of master branch (until 5.2.0 release) and try again (or you can use public beta on the Play Store or a nightly build from https://download.linphone.org/snapshots/android/).

Thanks in advance,

[driesken]

Hi @Viish ,

I've disabled opus on the server this time to ensure alaw for both parties but that doesn't have any effect. I've recompiled my linphone version with the latest SDK as you suggested but unfortunately didn't notice any improvement.

Just to make sure, I've attached logs from a the latest nightly as you suggested (only reproduced the delay here with one incoming call). This attempt was reproduced on a Samsung Xcover 5, just to make sure...

637ce47c40130_6c95cd05b0c5a99732a7.txt

Kind regards

[Viish]

Hi @driesken,

Thanks for the new logs. Have you tried without any BT headset connected? Can you try with another audio codec? Can you try by calling using another linphone device (android, iOS or desktop)?

Thanks in advance,

[driesken]

Hi,

The calling party in this case (64268) was also an Android Linphone instance. When the bluetooth headset is disconnected, I'm not experiencing any delay when answering incoming calls (also when BT remains enabled on my Android).

I've just tried MicroSIP (Opus) -> Nightly Linphone (Opus, with BT headset) which also induces massive delay. Without headset, no problem.

I've been testing under a lot of different circumstances (WiFi work/home/4G), between different parties (SIP, PSTN, ...) but the delay always occurs when answering a call with a bluetooth headset. I've tried several models like the (new) Microsoft Wireless Headset, Jabra Evolve 65, PT Legends, ... I must admit that I've only tried this on different Samsung devices (S10e/Xcover 5).

Would you like me to provide logging for a specific case?

[Viish]

Please do one last test for me: disable "Improve bluetooth connections" toggle in Call settings and try again. If it still doesn't work please attach one last log of a call from linphone to linphone using Opus with the audio delay please (with the "Improve bluetooth connections" toggle enabled back ON).

[driesken]

I've disabled Improve Bluetooth Connections (TelecomManager), but it didn't show any improvement.

Here's a new log where 642680 is the caller (Linphone, Opus) and 242684 is the callee (Nightly Linphone, Opus, BT headset, Improve BT connections toggle ON): 637cfc090f3ee_fde7eade19c573e76d97.txt

When making a call from 642680 (with BT headset) to 242684, there is almost no delay (+- 50ms)

[driesken]

I've done some more testing between Linphone and another Android SIP client (also using Opus codec). When I answer incoming calls with that client, I don't experience the same delay as I do with Linphone. Just saying that this probably isn't infrastructure/BT headset related.

[driesken]

Hi @Viish

I've done some more testing on a Samsung device (S22) regarding this issue. This time I've used a Jabra Evolve2 50. During my tests, the initial jitter when answering a incoming call (according to the in call stats) was around 480ms which made a fluent conversation very hard. The jitter decreases incredibly slowly. After 1m30 in call, it was still about 139ms.

For the second calltests I've set "audio_adaptive_jitt_comp_enabled" to 0 which resulted in most calls having a jitter of around 60 ms. This sounded much better.

For the third calltests, I've tried setting "audio_jitt_comp" to 0. After a few seconds of delay (even though the in call stats indicated a jitter value close to zero), the jitter remained nearly zero and the calls became even better. After a second or 8, there was almost no hearable delay anymore.

I've finally tested the Samsung XCover 5 but initially it was way worse than the Galaxy S22. Reported jitter was around 680ms. Even though adjusting above jitter parameters had some positive impact, the app was pretty unresponsive each time a call was answered over the bluetooth headset. It would take up to 5 seconds before any audio is received. The ringing is also briefly interrupted which would indicate that the "volume hack" could be applied? I've attached some logging of the Xcover 5. 64f5d602aebdc_eaa6d2212c1d307ded10.log

So my conclusion would be that the adaptive jitter compensation must have something to do with it. Do you think it is usefull for me to do some more testing and deliver you the logs?

PS: I would like to add that I don't experience any delay when answering calls on Linphone for iOS with the same headset connected. So I don't suppose it is SDK or network related?

[driesken]

Hi @Viish and @smorlat Is there anything I can provide in this matter? We're currently in the process of getting paid Linphone support. Should I open a new ticket in mantis afterwards?

[Viish]

Hi @driesken,

A fix is available in 5.4.0-alpha.294 and newer. We will keep using it for a while, and if we do not find any regression we will apply the changes to 5.3 as well.