#119 Echo problems tracking issue

[Anonymous]

Originally created by: tdbj...@gmail.com
Originally owned by: r3gis...@gmail.com

What steps will reproduce the problem?
1.  Using google voice
2.  Gizmo 5 servers
3.  And csipsimple speex codec 16 and bandwith audio set at 16

What is the expected output? What do you see instead?
Clear audio, callee received massive echoes after everything they said

What version of the product are you using? On what operating system?
Using the latest in the download section 12.06

Please provide any additional information below.
Massive echo on the call received end after everything they say.  Seems to be a polar issue as the callee either has a massive echo or does not.  All my settings are the stock settings.

[Anonymous]

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

What do you consider a big tail length?

[Anonymous]

Originally posted by: k...@laberteaux.org

I've  been using 800 msec.  I don't know if that is optimized.  Basically, you want the tail length to be just long enough to cover the turn-around time of the echo, but no longer.  The convergence time of the echo canceler is inversely proportional to the length. I'd experiment with various lengths from 100 msec to 10000 msec.

[Anonymous]

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

Issue 775 has been merged into this issue.

[Anonymous]

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

Quick update from issue 775 in english this time:

I've installed CM7 on my SGS, and very good news, there is a new audio mode to allow VoIP apps to use a clean audio mode ! (once again this mode has been introduced by google cause they need it for their own stock sip stack)... But good news it can benefit all apps :)

More amazing, there is already a way to use it in current csipsimple (if you have a CM7 on your SGS...) simply go in audio workaround settings of csipsimple and activate "MANUFACTURER_EXTRA" mode :). It was added here cause one manufacturer contacted me directly to have SIP support on their device and we choose exactly the same value than the one choosen by google :) lol...

[Anonymous]

Originally posted by: rolf.leu...@gmail.com

I have the same problem: echo on the otherside
My setup: Xperia X10 Android 2.1, Sipdroid 2.1, pbxes.org account, try all codecs. Other side: Try all devices (landline, cellphone, other SIP), always the same problem.
This problem makes Csipsimple almost useless for me, because many times the other side asks me to call them from "normal" phone, because the echo is unbearable for them.

[Anonymous]

Originally posted by: tim.chip...@gmail.com

Hi, Just to add to the thread, FYI: Got a new LG P500h phone yesterday, install csipsimple fresh from android market. Once configured, I have same issue - whoever I call hears themselves in 'faint but audible 1x echo' with ~half second delay after everything they say.  This is with a VOIP SIP service I've used for >2 years previously with a standard grandstream VOIP ATA unit and had no issues with.

-Tim

[Anonymous]

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

It could be interesting to test latest nightly build and to try to change the micro source option (see the wiki entry about audio routing troubleshooting to activate workarounds for audio routings).
At least it helped on official X10 rom where changing from Default micro source to Voice call micro source solved the problem.
However it will not work on all roms and all manufacturer : this kind of problem is really linked to the way the manufacturer interpret the android audio api.
In android 2.3 it will be much much more clear since google has fixed things and added a micro source and an audio mode specifically for voice over IP. But previously it depends deeply on the way the manufacturer decided to implement things. Basically the reference I always took was the HTC implementation (cause they worked with google on first phones).
Now all manufacturer seems to adopt this implementation (even samsung after google worked with them on the nexus S). But there is probably other manufacturers that are not yet aware about how to implement things cleanly on old ROMs.

If you find interesting things by trying to play with the audio routing troubleshooting options do not hesitate to share, I can automatically activate some option on some devices if it helps. (I already do for devices I had feedback for)

[Anonymous]

Originally posted by: tim.chip...@gmail.com

Hi, thanks for the quick followup. I tested a bit more, and observed,

- csipsimple is working now - without echo at other end - but I can barely hear the person at the other end of the line.  They are audible, but only barely (if I'm in a silent room).

- I did a test install with 3cx SIP softphone and found it had some issues also: Initially no audio; but if I toggled speakerphone on then off, I had audio but also an echo audible to person at other end (ie, they heard themselves echoed 1x ~1-2 seconds later) - similar to issue I observed with csipsimple.  As you say it makes me wonder about implementation of android on this LG device.

I will try to get a more recent nightly build and see if things are any different.

Thanks,

-Tim

[Anonymous]

Originally posted by: tim.chip...@gmail.com

Hi, small footnote: I got the May-1-11 nightly build, and after increasing the amplification from default of 1x to 5x for speaker volume; I could hear the person on the phone fine. No echo at either end. I then tried to play with codec settings a bit and have managed to render it impossible to call out or on; so have some more fiddling to do. But had good luck with the adjustment; so making progress.  --Tim

[Anonymous]

Originally posted by: k...@laberteaux.org

Well, I think this is a breakthrough! (At least for me :-)

No echo!

Following Tim's experience, on my Nexus One, running CM6.1.1 (plus wildmonks's kernel without the audio boost), using the [r822] nightly, I was able to use the Audio Routing hacks (https://code.google.com/p/csipsimple/wiki/FAQ?tm=6#Audio_routing_troubleshooting) to reduce/eliminate my echo.

T be more precise, checking the "Use Mode audio API" seemed to work the magic.  Individually checking the routing API and Tone Hack had either no effect or minimal effect (I haven't done comprehensive testing yet).  However, the Use Mode Audio API hack (having it checked) worked!

In fact, it worked so well, I actually turned off the echo canceller (unchecked the "Echo Cancellation" option at the top), and still no echo (so far)!

Frankly, this makes a lot of sense.  As I mentioned above and in a posting on another site (http://bit.ly/i5jMQd), I've been chasing this Android/VoIP/Echo thing for a few months.  The echo I was hearing (often almost 1 second later) was not likely acoustic echo.  It seemed that there was a software bug that caused the echo.  Your hacks, and the fact that they reduce echo for me add further support to this theory.  It also makes sense that there is a bit of "variety" in how some of these audio APIs are executed, and this is a core issue.  Glad to hear that the later versions of Android will help here!

So, can you tell me what the "Use Mode Audio API" hack actually does?

I will also say that, like Tim, enabling this hack seemed to reduce the volume of the csipsimple talker (i.e. the microphone volume on csipsimple needed to be increased).  I actually increased it all the way to 10x, and it seems to work well.  Clearly we are working with some hacks here, but at least this gives hope for the future!

Great job, and thanks for your efforts!

[Anonymous]

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

Good news.

Ok so I'll try to be a little bit more exhaustive about these hacks and what it does.

* The 'Use routing API' : the routing API is the old (android 1.6 and lower) audio routing API. Using this API we have to explicitly say where output goes. This API is deprecated since android 2.0 but some manufacturer still use it and sometimes it do things better than the new API (with setSpeakerphoneOn). The doc of this API is here : http://developer.android.com/reference/android/media/AudioManager.html#setRouting%28int,%20int,%20int%29 (you'll notice that it's marked as deprecated).

If we don't check this option csipsimple tries to route using the new API (setSpeakerphoneOn).

* The 'Use mode API' (the one that make things better for you) : Here comes true hacks... In fact android audio API has something called mode. My understand of these mode is that it is some kind of "preset" that the audio layer has. I initially thought that MODE_IN_CALL was the good mode... however after talking with guys that implements things for some manufacturer, I understood that it was not a good idea and that the good mode to be sure it will be compatible with all devices will be MODE_NORMAL. The reason : some manufacturer use MODE_IN_CALL to directly plug the micro to the GSM chipset. As consequence in this mode audio packets are not always distributed to the application layer. Besides in this mode nothing ensure that setSpeakerphoneOn will works properly.
But, sometimes the MODE_IN_CALL mode is the only way to get routing to go through the earpiece.
So the 'Use mode API' use MODE_IN_CALL when you route to earpiece and MODE_NORMAL when you route to rear speaker. It's possible that some ROM does use hardware echo cancellation when MODE_IN_CALL is set (or use better preset for audio driver). However since the goal of this mode is GSM call nothing ensure that micro will works properly (you can have nothing at all or really quiet sound). It explains what you observe on your ROM.

* The 'Audio mode for SIP calls' option is linked to the previous. While the previous play with MODE_IN_CALL and MODE_NORMAL, this one allow you to replace directly MODE_NORMAL by another mode (and mode in call is never used unless you select it explicitly). In android 3.0 there is a new audio mode : MODE_IN_COMMUNICATION (it's also available on some android 2.3 device as private api).
This mode is the thing we expect from long time. In this mode, google said : this one is for SIP calls !! So manufacturer has no more excuses . In this mode they have to do things cleanly so that there is no echo with micro ! If they do not the stock SIP app will not work at all, and I hope they check that. So if you are running android 2.3 or upper csipsimple will automatically try to activate this mode. Results are impressive in this mode. On my acer iconia tab, even with speaker set to maximum there is no echo at all !

* The Galaxy S hack : first samsung hack... before android 2.3 and their work with google on the nexus S, samsung did things a really weird way on their device. With galaxy S it was the worse they did. It was not possible to get routing going through earpiece unless you use something I found after days and days of tests. It's the galaxy S hack. The audio mode explanation already give you headaches? ... well that was just the beginning... the galaxy S hack works as follow : it first enable audio mode MODE_IN_CALL and directly after it activate the MODE_NORMAL. Why? Because MODE_IN_CALL activate presets that does the correct output routing to the earpiece (but route the micro to the GSM chipset and not the app) and then MODE_NORMAL does the routing of the micro without modifying the output routing !! That's obviously a "bug" in the samsung driver (or at least something not consistant at all), but that's a chance cause else we could have absolutely no way to get the correct routing. That's why I sometimes want to cry when samsungs users cry about the fact they have echo : they already have a LOT of change to have something that route properly. It's already very very tricky to work with what samsung did!

* The audio tone hack : second samsung hack ... other devices from samsung has another weird behavior -almost each one re-interprete the audio api ;) -.
Using the normal mode, one of their device has some timer that after some very short time of inactivity close the sound device. Which is really annoying when you start a call cause RTP stream can not be established immediately. As consequence this hack just produce a quick and not audible sound at start of the audio.

* Micro source : it allow to choose the micro source for the audio. Previously I always used DEFAULT, but now with android 3.0 (and some 2.3 as private API) there is a new source "VOICE_COMMUNICATION" that is specifically done for SIP calls and just like the MODE_IN_COMMUNICATION should really help with hardware echo cancellation and proper routing. Some device require to change this value - for example the motorola atrix.

For reference the relevant code about all of that :
https://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/src/com/csipsimple/service/MediaManager.java#229

And the default settings for each device I had feedback for:
https://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/src/com/csipsimple/utils/Compatibility.java#87

Hoping that could help other opensource project to solve their problem with the audio layer ;). Or if any has more experience than me or things to add on this point, do not hesitate it will be welcome :)

[Anonymous]

Originally posted by: k...@laberteaux.org

Thanks for a great write-up, and I think this work will have an outstanding contribution to those battling echo on pre 3.0 devices.  I will note that I had roughly the same echo on lots of other voip programs, including those by Obi, sipdroid, etc.  I will try to spread this posts to the other voip software devs!

So to be clear, even though you first thought that MODE_IN_CALL was the proper default, you switched the default to MODE_NORMAL for compatibility?

Since I never used the speaker phone, on my nexus one (Android 2.2), with Use Mode API checked, audio routing is MODE_IN_CALL, while with it unchecked it is MODE_NORMAL

[Anonymous]

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

I'd like to confirm MODE_IN_COMMUNICATION working great on my Nexus S running Android 2.3.3 and nightly build [r813]. CSipSimple automatically set this mode (AFAICT). At first I didn't understand why the voip.ms echo test number was working so well. Now I do :-)

Nice work!

[Anonymous]

Originally posted by: k...@laberteaux.org

Just another follow up.  I've found that echo is now gone (when I perform the Use mode API hack) when just using my handset.  But if I plug in a wired headset (with mic), the same old echo returns.  Makes sense, as insertion of a headphone is likely to change the audio routing.  Any way that you can force the "Use mode API" when using wired headsets (haven't tried bluetooth yet)?

By the way, my sip provider is showing some love to csipsimple:
http://www.ipcomms.net/support/support-csipsimple-android-how-to-install.html

Maybe they deserve a little love back by way of a wizard ;-)

(I also pointed them to this thread if they want to learn a bit about echo issues).

[Anonymous]

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

About changing mode for headset, I will have a closer look, but for now not possible with the current code.
But could be interesting to have audio troubleshooting params per output (normal, bluetooth , headset).
This morning I've noticed that on android 2.3 the new mode MODE_IN_COMMUNICATION does not allow to use Bluetooth... So I've added a test to fallback to mode normal if bluetooth is detected. Could be interesting to allow to fallback to other modes cause I would not be surprised if some other devices requires MODE_IN_CALL to have bluetooth working.

As for IPCOMMS wizard => I've just created issue 933. :)

[Anonymous]

Originally posted by: k...@laberteaux.org

Is "Audio mode for SIP calls" only available on Android 2.3 and above?  I am anxious to try "MODE_IN_COMMUNICATION".  My phone is Android 2.2.1.  Is this "dangerous" to play with?

[Anonymous]

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

Not really "dangerous" : I mean it will not break the phone (audio mode are reset after reboot).
I'm sure that it will not work (on android 2.2.1) because this mode was not there is the android 2.2.1 source code. Audio mode may not raise an exception. It will just probably fallback to default. The micro mode will raise an exception but I managed that in CSipSimple : so that it will fallback to the default micro source.

The only risk is that the audio mode raise an exception which will make the call crash. So if you are making an outgoing call make sure you are able to terminate the call on the other side ;).
After that, just restart csipsimple, it will (it should ;) ) restore previous settings (wifi sleep policy mode, audio mode, ringer mode). If it does not restore properly restart the phone and ensure the wifi sleep policy mode has not been changed to something you don't want (many apps change that and it drains the battery much faster, csipsimple also do this change but just for the time of the call if over wifi).

[Anonymous]

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

Issue 954 has been merged into this issue.

[Anonymous]

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

Recently updated my Nexus S to Android 2.3.4 and echo suppression seems to no longer be working (wifi and 3G) - build [r813]. Have confirmed that "Audio mode for SIP calls" is set to "IN_COMMUNICATION".

Would installing a later build help? If so, any suggestions as to which one?

Thanks

[Anonymous]

Originally posted by: seo.siem...@gmail.com

On my galaxy S with 2.3.3 echo is greatly reduced when setting MicroSource to VOICE_RECOGNITION

[Anonymous]

Originally posted by: k...@laberteaux.org

I have updated to Blandroid 2.3.4.  I still need to use "Use Mode Audio API" to remove the echo.  Also, as before, when I use a wired handset (Nexus 1), the echo returns.

[Anonymous]

Originally posted by: m...@mykohsu.com

I can confirm that on 2.3.3 GB there is no echo using cSipSimple defaults for GB. However, interestingly the GB built in SIP with the same account has echo. I have not tried 2.3.4 yet but I suspect the echo will return in cSipSimple though it may be fixed in the built-in OS SIP.

Ken: Do you still have echo on 2.3.4 if you use VOICE_RECOGNITION?

[Anonymous]

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

Just for info, the stock SIP app use VOICE_COMMUNICATION as source and MODE_IN_COMMUNICATION as audio mode (which are the default in CSipSimple and 2.3 and upper).
(I've read the code of the stock SIP application and that's why CSipSimple default settings are these ones).

Both are new API introduced in 2.3 code for the SIP application. Obviously manufacturer/ROM makers has to support it. But the goal of this is explicitely to use hardware echo canceller and to have things preset just for voice over IP calls.

Normally this new API is there in the android code as private api from android 2.3. If the ROM include and support well the stock sip app, this new api should work.... But it entirely depend on how the manufacturer implement things in their driver.
This new api is "official" in android 11 (android 3.0) so all manufacturer must support it on 3.0 and upper.

This is just how it *should* work. However audio is really touchy and each ROM and manufacturer implement things differently without really following the reference as it should be. As consequence, CSipSimple hacks could be useful and will permit to always have a way to be compatible the best possible way. (so in 2.3.4 if the echo is suppressed in the built-in SIP app, just change csipsimple settings to have the official API... and it will works as well !)

[Anonymous]

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

Changed the amperage to 5 now it works perfectly no echo at all.

[Anonymous]

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

@sofly : really interesting ! How did you changed amperage?
I guess some other users will be really interested in that point (maybe I could document that somewhere too).