#2838 Nexus 4 + Lollipop : Remote-end echo

[Anonymous]

Originally created by: bill.out...@gmail.com

What steps will reproduce the problem?
1.Nexus 4 + Android 5.0 Lollipop (+ OVH Sip service or private Asterisk)
2.CsipSimple with default settings
3.Place phone call and ask the other end about the echo...

What is the expected output? What do you see instead?

The correspondant at the other end hears his/her voice back.
Depending on echo cancellation settings, buzzing noise can be heard as well.
With previous Android KitKat, no such noise / echo on the far end.

What version of the product are you using? On what device / operating
system?

Latest CsipSimple trunk.
Android 5.0 Lollipop

Please provide any additional information below.

With Android 4.4, I once noticed some surprising behavior, See :
https://groups.google.com/forum/m/#!topic/csipsimple-users/Nn-j1zRqeo4

It seemed that whatever echo cancellation setting you might use under 4.4, hardware echo cancelation was 'always on' as long as "Mode Audio API" was enabled.

With Android 5.0 it seems different, in fact "Mode Audio API" doesn't seem to have much effect anymore.
Tried verious echo cancellation modes / trail timing, with no success.

[Anonymous]

Originally posted by: bill.out...@gmail.com

It seems that Android 5.0 for Nexus 4 just ignores Audio Mode ?

Whatever AudioManager::setMode() you set, there is just no difference.
It still operates in 'Normal' mode.

[Anonymous]

Originally posted by: immanuel...@gmail.com

I can confirm this issue with my Nexus 4 (Lollipop). I'm also having the same issue with my Nexus 7 (2012, Lollipop). On all other devices we own (HTC one mini and HTC Desire with CyanogenMod) echo cancellation works brilliant.

It seems echo cancellation is working but much too weak. Because there is a difference in enabling or disabling echo cancellation.

Currentl the trick is to make the micro less sensitive (-4.0 dB).

[Anonymous]

Originally posted by: rel...@gmail.com

It is the same here...

[Anonymous]

Originally posted by: bill.out...@gmail.com

Some update on the topic.
My comment #1 was wrong, AudioManager:setMode and AudioRecord modes are working as expected.

I did some tests with code samples, simple echos with both OpenSL and Java and here is the thing :
- with 4.4 kitkat and below, using IN_COMMUNICATION + VOICE_COMMUNICATION triggers automatically the built-in hardware AEC. With both Java & OpenSL
- with Lollipop, this is no longer the case.
This explains why call was fine under Kitkat even with "Echo cancel" setting disabled.

What are the alternatives ?

- Software Echo cancellers or lower micro gain ?
There is some improvement, but audio call still feels "weird" on the remote end. Especially with devices (nexus 4) which are very prone to headset echo by design.
Side note about soft echo cancellers, the less audio latency, the less efficient they seem ?
Digging the code to see how they work is just over my skills :)

- Using Java audio driver and implement AcousticEchoCanceler in it ?
It works, but there is a -huge- audio latency using this driver. Maybe it is JNI related, because simple In/out echo using AudioTrack / AudioRecord doesn't show much latency.
I am trying to rework android_jni_dev to see if latency can be improved.

- Implement AEC in OpenSLES driver ?

Should be the best option but,

* Though SL_IID_ANDROIDEFFECTCAPABILITIES reports an "Acoustic Echo Canceller", AudioRecorder doesn't expose a SL_IID_ANDROIDEFFECT interface. It seems (in current OpenSL implementation) it is only possible to apply post-processing effects.

* Use JNI to attach AcousticEchoCanceler to the OpenSL audio recording session.
Unfortunately OpenSL doesn't provide a way to retrieve the android audio session ID (even if looking at AOSP this ID actually exists).
I found a really dirty hack to attach AcousticEchoCanceler without knowing the session ID, and now call is working fine as before.
Still needs to work out releasing the resource when call ends, I will post the svn diff when it is OK.

On another side note, I took the initiative to insert a 48kHz option so OpenSL is granted AUDIO_OUTPUT_FLAG_FAST and AUDIO_INPUT_FLAG_FAST, so there's now near-zero audio latency.

[Anonymous]

Originally posted by: immanuel...@gmail.com

Despite of the dirty hack in OpenSL_ES this bug should be sheduled against Google Android imho.

I tried the native Google SIP client. It shows the echo problem very clearly, while a regular GSM call shows absolutely no echo! So the question raises, whether the native android AEC can be acessed through an API or if one has to reimplement AEC a second time in OpenSL ES.

[Anonymous]

Originally posted by: bill.out...@gmail.com

See :
http://pastebin.com/VuzQ6jD7

Please consider it as an dirty, untested hack. It is not guaranteed to work on any device but Nexus ones (will likely crash on any other), and even on Nexus it is not guaranteed to be stable at all !

However hardware AEC is back, and on my N4 prefered settings would be :
- disable (soft)Echo cancel (AEC being already there)
- set sample rate to 48kHz (fast track, reduces latency)
- disable Mode Audio API
- IN_COMMUNICATION / VOICE_COMMUNICATION
- openSL ES
- raise Mic Gain (AEC seems to reduce mic volume)

Regarding bug report to Google, I read hear and there that google has already been reported that :
- SL_IID_ANDROIDEFFECT cannot be applied to OpenSL recorder
- audioSessionId should be available in OpenSL (it is said in a 2012 post that "Google is tracking it internally")

I also agree that native SIP is far behind CSipSimple (audio quality, echo, latency). Unfortunately it doesn't look like a top priority to AOSP...