Massive lag when toggling speaker during a call

[ParticleCore]

Hi, I've been facing this for a while now, but I always thought it was something I had incorrectly set up, but today I got the chance to confirm that same issue is also present in the Play Store Linphone app.

When I initiate a call and after it starts ringing I toggle the speaker option the app lags a lot, and it gets worse the more times the speaker button is toggled to the point of causing the audio to crackle and UI drag. The issue stays like that for the rest of the call too, and in some cases it stays like that after terminating the call and starting another.

Is there any way we can work around this issue or a reason behind it? Often times we need to switch to speaker when starting a call and then enter DTMFs, but because of this issue the DTMFs start getting garbled, the audio feedback suffers massive delays, and the whole experience is sub-par.

I tried to find a reason for why this happens, but the logs did not show anything obvious.

Tested on both Play Store Linphone 5.2.4 and Library SDK 5.3.37

[ParticleCore]

Attaching app logs from test done with the SDK.

logs.txt

Logs represent the moment the call is initiated and the speaker button is toggled multiple times and then the call is terminated manually.

[Viish]

Hi,

Indeed there is ring ticker is quite high: W Ring MSTicker: We are late of 911 miliseconds. I'll see what I can do.

Cheers,

[Viish]

Hi,

Could you try latest SDK from master branch (5.4.0-alpha.169)? It should improve that.

Cheers,

[ParticleCore]

@Viish It feels a bit better, not by much, but the problem seems to be present still. It got to a point where the incoming audio would not be heard, and eventually it would play at what sounded like x2 speed until it caught up with the real playback time, I guess? If you try it yourself you will see what I am talking about, just toggle the speaker multiple times in a row and it will quickly "pile up" the issue, incoming audio crackles, then goes silent, and any sent input suffers massive delays.

[Viish]

You may want to try using OpenSLES audio driver instead of AAudio : it has been deprecated by Google and offers a less control on which device is being used compared to AAudio, but switching from earpiece to speaker is must faster.

[ParticleCore]

It has now become bearable with openSLES preference, but the issues are still present nonetheless.

Still it is more tolerable than it was before, so at this point this will work, but feels like it shouldn't be doing this. I've not had this issue with other apps, so it was quite noticeable to me when I faced it.

[Viish]

You could also disable the toggle button while the audio stream is restarting and thus prevent this issue from happening, but I guess there aren't a lot of people that will do that in real life scenarios...

[ParticleCore]

If I can detect when the audio is still not ready, or has restarted, that would be a nice way to mitigate the problem I imagine. However, I've been trying to dig in the code to understand which API from the SDK I can use for that purpose, and I am having trouble getting anywhere with that, nor could I find anything obvious in the docs.

Are there any pointers for this?

[ParticleCore]

@Viish An odd situation is now occurring with the 5.4.0-alpha.169. When initiating a call it is automatically playing the ringing tone on the speaker, and no matter how many times I toggle the speaker option it keeps playing the ringing tone on the speaker always. When the call is picked up, or goes into the voicemail, the audio correctly plays in the earpiece, or speaker if I enable the speaker at that time.

I rolled back to version 5.3.37 and the calling tone does correctly play in the earpiece when it should, and switches to the speaker when enabling the speaker. So something changed in that alpha version that affects this behavior.

[Viish]

I rolled back to version 5.3.37 and the calling tone does correctly play in the earpiece when it should,

What about using 5.3.40 or newer?

[ParticleCore]

I rolled back to version 5.3.37 and the calling tone does correctly play in the earpiece when it should,

What about using 5.3.40 or newer?

I tested with 5.3.47 and the problem is not there, do you want me to try anything else?

[Viish]

do you want me to try anything else?

No, thanks.

[Viish]

Could you attach logs showing the issue with 5.4.0-alpha.169 SDK please?

[ParticleCore]

Could you attach logs showing the issue with 5.4.0-alpha.169 SDK please?

@Viish I've collected these logs with that version.

logs.txt

The process was as follows:

1. Start call
2. Let it ring once (rang on the speaker even though it is configured to use the earpiece unless the user switches to the speaker)
3. Terminate call

[Viish]

Thanks, I see what it is. When using OpenSLES with STREAM_NOTIFICATION channel, it automatically routes the audio to the speakerphone... I made a change recently on master branch to have the ringback tone played on the right stream when using AAudio, but it changes that behavior for OpenSLES apparently... I'll make a fix to revert the regression on OpenSLES, thanks!

[Viish]

Hi @ParticleCore,

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.