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.

Some device such as the sony X10 has a special concept of the micro source and mix the micro with the output line. This cause a big echo since once you receive something it's re-transmitted. I have to debug this issue. I hope it is not linked to a bad audio implementation from the manufacturer.

Btw, two question to clarify things : What is your device? Did you try using another codec than speex and with another audio frequency (8kHz)?

Comment deleted

I found something interesting on a call yesterday. The callee was getting an echo, and I just turned down my in-call volume... the echo went away! Apparently the feedback from the earpiece, which I had set loud, into the mic was causing the echo. The (normal) delay in a VoIP circuit, combined with the earpiece to mic feedback, produced the echo at their end. My solution: reduce the Microphone gain to 0.6, then restore my in-call volume to the usual setting (good for both Mobile and SIP calls). My callee said my voice was still plenty loud.

Try this and report back. And try Voice Automatic Detection as well.

I used to work on echo cancelers for phone networks. Can you point me to the area of the code that does echo cancellation? Also, what is the metric of the Echo cancellation tail in the settings? samples? msec?

I am using a nexus one. I notice that if I physically cover the mics on the phone, or if I set the earpiece volume to zero, there is still an echo for the other party. That tells me that this isn't purely acoustic echo. Of course, if I reduce the mic gain to zero, the echo goes away.

I would think that a half-decent sip service would provide echo cancellation. But I haven't found one.

There is several backends for echo cancellation. (CSipSimple rely on pjsip library). For now I only use the simple implementation. (Tail is ms).

I absolutely don't know how it's coded and actually I'm not sure that I properly configure it ;) :

http://www.pjsip.org/pjmedia/docs/html/group__PJMEDIA__Echo__Cancel.htm

If you want to have a look and tell me what I should change in my settings or contribute to the pjsip library (this library is available on a lot of platforms : android with csipsimple and 3cx(close source), on iphone (siphon and forks), psp, pc, mac etc etc).

So if you improve their stack will benefit a lot of people ;).

On my Evo I also have a bad echo. Changing the Mic gain doesn't seem to have any affect. I can set my phone across the room with a mic gain of 0.1 and speak very lightly, indirectly at that, and still hear me voice. However when muting the call the echo is gone.

I would be happy to try to help. However, I am a complete newbie to code.google.com, and my coding chops are not what they used to be. So I would need some hand-holding.

Here are some ways we can start:

Can you show me how to view the source (or pseudocode or similar) for pjmedia_echo_create() and pjmedia_echo_cancel()?

I am pretty sure you don't want the echo state to be PJMEDIA_ECHO_SIMPLE. From the documents, that essentially turns off the acoustic echo canceller, creating simplistic echo suppression (probably a squelch or similar). We should try PJMEDIA_ECHO_DEFAULT

Note that echo cancellation can be computationally expensive. As we test, can you keep an eye on the resources consumed? There are tricks to cut this down, once we get something working...

I've now (latest dev releases in trunk : http://nightlies.csipsimple.com/trunk/ ) added an option to change the echo canceller type you'd prefer.

One really important thing to know is that by default I try to choose options that will ensure the best compromise for all devices. It mean even those with low CPU. Choosing SIMPLE seems to be the best compromise I get when I tested that over my 8 android phones ;). But maybe I should retest now since I've tweaked other parameters in the native stack. At least now in latest dev builds, there is a way to set the echo mode. (see ExpertSettingMode to turn on expert settings).

For the code of the echo canceller you can view it * on my copy of the pjsip trunk; probably here http://code.google.com/p/csipsimple/source/browse/#svn%2Ftrunk%2Fpjsip_android%2Fapps%2Fpjsip%2Fproject%2Fpjmedia%2Fsrc%2Fpjmedia * or directly on pjsip website : http://trac.pjsip.org/repos/browser/pjproject/trunk

I'm not sure that I'll be able to help you a lot about the implementation in itself cause this is done by pjsip guys (if you have remarks maybe worth to tell them directly and share on the pjsip mailing list). Also what could be interesting, if you have some proposal of an implementation of the echo canceller (really different from an existing one) is to have your own echo canceller module : pjsip is well design as far as I can tell and will probably allow to implement easily a new backend for echo cancellation.

I can't say for the entire pjsip project, but at least if you do such a contrib, I'll use it in CSipSimple ;)

Thanks for doing this.

Could you also expose the latency_ms variable in the echo canceller? This will allow you to put the canceller taps a little further out in time without having to increase the tail length. Extending tail length slows the convergence of the EC.

Also, could you confirm that it is not necessary to exit and restart the program for these settings to be made?

Also, please confirm that Echo Mode=Auto means that the echo type is PJMEDIA_ECHO_DEFAULT

Yes Auto = ECHO_DEFAULT

For the latency ms not easy to add the setting. The interface that I can configure is this one : http://www.pjsip.org/pjsip/docs/html/structpjsua__media__config.htm

The apps take settings into account as soon as you leave setting panel (it restart the native sip stack).

I agree that this interface is not so clear, but perhaps you can clear something up.

I ran a log and found this line:

D/libpjsip( 1246): 15:37:49.150 ec0x381dd8 Echo suppressor created, clock_rate=16000, channel=1, samples per frame=320, tail length=800 ms, latency=100 ms

Where did the latency=100msec get set?

Probably automatically computed : http://code.google.com/p/csipsimple/source/browse/trunk/pjsip_android/apps/pjsip/project/pjmedia/src/pjmedia/sound_port.c?r=472#562

But I'm not sure

Is there any way we can over-write the values here:

http://www.pjsip.org/pjsip/docs/html/structpjsua__media__config.htm

perhaps using a config file, so you don't have to mess with a gui?

As for theses values I can give you a direct access to it in the GUI. (it's part of the pjsua (ua) API)

Which one do you need?

(there is already unsigned ec_options => Echo mode unsigned ec_tail_len => Echo Tail length + activate echo )

Do you need values for jitter buffers?

Does ec_options give you direct access to pjmedia_echo_create()? If so, that might be the ticket.

Yes, the jitter buffer options would be nice, but I was going to start with snd_rec_latency and snd_play_latency.

Basically, the shorter the latency, the longer the tail length needs to be, but long tail length means slow convergence

There may be some other ways to go at this as well. A good way to train an EC is to feed it some wide-band noise. Perhaps we could try that.

Also, it seems odd that the echo is not really affected when I cover the mic with my finger. Acoustic echo should basically go away if you perform this "analog mute". It makes me think that the software intentionally is feeding back some of the received signal. This was done in the past to give the far-end talker a nice "reverb" sound to his voice, but is a disaster if there is delay in the line. Do you recall seeing anything about this?

About first point : ec_options is what is in the interface of CSipSimple echo mode. I think that it impact more or less directly echo_create yes : My code : (line 254 ) http://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/src/com/csipsimple/service/PjSipService.java?r=485#254 And according the doc of pjsip for this option : """ Echo canceller options (see #pjmedia_echo_create()) """

So I guess it's finally the same parameter :)

Ok, for latency I'll add that but I've first to check that it's really useful cause maybe directly given to the audio "driver" which is mine implementation and take only care of what is provided by the android API to get best results.

As for your last point.... well in fact that's what I think to be the cause of the problem. Cause pjsip is known to be reliable and I don't think that I use it an odd way and actually I've no echo at all on most of the devices I test.

Actually, on some device, some crappy manufacturer implement the android audio stack just like they want... Btw, when you try to use it a standard way you can get really unpredictable (from a device to another) results. For example on samsung device their big problem is to implement correctly audio routing... reason why you'll find over the web a lot of problems with these devices + voice over IP applications. Other, was the case for the XPeria X10 (a lot before the 2.2 upgrade but still observable now), has something really really annoying : when a third party app tries to record micro input.... it also get packets from audio output !!!! And so we get echo... that's a logical consequence... In this case nothing can be really done (except tuning audio amplification for micro and speaker).

There is some recent (but not compatible with all android versions) API that allow a more fine choice of micro channel and speaker channel. But (as not compatible with all android versions), I've not yet really tested this new API.

Maybe something that I should have asked before but : @ken & @tjborn : what device are you using?

If you get a really big echo, that's not something "normal" on phones I can test on, (nexus one, galaxy s, x10 mini, archos 5it, galaxy i5500, desire HD), I don't observe echo (or really quiet unless of course I use the two phones on the same room and I put them on speaker :) ).

I use a Nexus One using CM6.1 (Android 2.1). I've recently changed the echo canceller type to Speex and the EC tail length to 1000 (ms), and my echo is much reduced. Other info: codec=gsm, sipgate + pbxes.org. With this EC config, csipsimple uses between 10-20% of the cpu running at 998.4MHz.

I need to do more testing, but there might be some value in exposing the EC type and providing some documentation around it. The default EC mode I believe simply provides suppression:

http://svn.pjsip.org/repos/pjproject/trunk/pjmedia/src/pjmedia/echo_suppress.c

" Processing:

Once learning is done, the ES will change the level of the mic signal depending on the state of the conversation and according to the ratio that has been found in the learning phase above."

I understand that you don't want to overtax the resources, but with proper documentation (or adding to the FAQ), it might be a helpful option.

Comment deleted

Issue 569 has been merged into this issue.

Can you point me to the code that runs the speex ec mode? I haven't been able to locate it....

I think that : * http://code.google.com/p/csipsimple/source/browse/trunk/pjsip_android/apps/pjsip/project/pjmedia/src/pjmedia/echo_speex.c?r=564 is the wrapper * And the implementation of speex echo canceller comes from the speex third party : http://code.google.com/p/csipsimple/source/browse/#svn%2Ftrunk%2Fpjsip_android%2Fapps%2Fpjsip%2Fproject%2Fthird_party%2Fspeex%2Flibspeex

Just a guess. I'm not sure at all. As usually pjsip is designed to allow several backends for doing a piece of work. Here several echo cancellation backend can be plugged to pjsip and used by it.

I've recently added SILK codec (it also had builtin echo cancellation, maybe could be interesting to see if this echo cancellation backend could not be plugged to pjsip). What do you think? Have you an idea on the quality of silk vs speex vs the simple pjsip backend?

Yea, I couldn't seem to find the relevant code from those pointers. Thanks for posting all the same....

Any idea on what providers support SILK so that I can try it out?

Thanks!

For SILK you can try SIP client to SIP client with a provider that do not media gateway.

For speex after quick search over google something that may help you : http://www.speex.org/docs/api/speex-api-reference/group__SpeexEchoState.html

Seems to be the used method by the pjsip wrapper. And after a simple grep : $ grep -lir speex_echo_cancel . ./mdf.c

So probably in mdf.c of libspeex ;)

Ok. Some good info here for possible troubleshooting of my speakerphone echo issue. But... the issue I am most concerned about is people sometimes not being able to hear me until I toggle speakerphone on and then back off. It happens randomly whether the call is incoming or not. Im not sure that issue is directly involved with this one. Any ideas where I can start to troublshoot?

@NameBrandHuman : yes sorry didn't read the title of your issue, I'll reopen the other issue and add precision. The fact that toggling speakerphone helps is something that was also reported by other users, so I'll reopen your initial issue and give you more info about what you could test. Sorry

Quick update, I've just noticed that speex echo cancellation was not fully enabled :/

You can now test revision 590. With speex echo mode and a big tail length; could help...

What do you consider a big tail length?

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.

Issue 775 has been merged into this issue.

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...

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.

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

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)

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

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

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 (http://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!

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 : http://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: http://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 :)

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

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!

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).

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. :)

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?

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).

Issue 954 has been merged into this issue.

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

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

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.

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?

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 !)

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

@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).

In expert mode/media settings/Micro amplification/changed from 1 to 5. Also did the'Use routing API'/'Use mode API'/'Audio mode for SIP calls'/& Micro source changes that you mentioned in comment 38. Device: Droid Incredible

@mykohsu on my Nexus one with Blandroid 2.3.4, the only way to remove echo is to select Use Mode audio API. I tried VOICE_RECOGNITION, and it had little or no impact. My default settings are micro source: VOICE_COMMUNICATION and audio mode IN_COMMUNICATION.

Note that echo is cancelled well when I use Mode audio API, but only when I use the normal handset pressed to my ear. If I turn on either the speaker phone, or if I plug in a wired headset, the echo returns. That again points to the fact that audio routing is the culprit.

@r3gis, is there any way to do some re-routing hacks when I use my wired headset?

Issue 1160 has been merged into this issue.

Helpful hack for HTC Incredible (with android 2.3) : Issue 1160 .

Issue 1135 has been merged into this issue.

Hi all, We had the same issue in IMSDroid (http://code.google.com/p/imsdroid/) and we were using Speex echo canceler. We finally fixed the issue in our latest release (imsdroid-2.0.448-webrtc) by using Google's WebRTC AEC (http://code.google.com/p/webrtc/). The source code of our implementation is available here: http://code.google.com/p/doubango/source/browse/branches/2.0/doubango/tinyDAV/src/audio/tdav_webrtc_denoise.c

Please note that for now we only enable AEC on ARMv7 device to avoid CPU overhead.

Very interesting point. I'll also try to include as much things as possible from webRTC. Thanks a lot for sharing !

I was first thinking about codecs, but indeed echo canceller is probably also very interesting to add.

Well, WebRTC echo canceller is ready to land in CSipSimple. (was pretty easy to integrate to pjsip). It will be available to test in next build. For now there is not the noise suppressor yet.

@mamadou : did you try the aecm (mobile) implementation? I was wondering if it was not something interesting to try out for armeabi target.

Available as r995 : http://nightlies.csipsimple.com/trunk/ Let me know how it goes, maybe could be default instead of speex echo canceller for armeabi-v7a devices?

I downloaded CSipsimple.ak from here: http://nightlies.csipsimple.com/trunk/CSipSimple-latest-trunk.apk To enable the echo canceler: Menu -> Options -> Média -> Annulation de l'echo. I'm using Samsung Galaxy S (Android 2.2) and calling iPhone client with built-in echo canceler but I have echo. I can't say if it's better or not because the last time I tested CSipSimple it was in 2010. What is sure is that it's possible to get it working on CSipSimple (not the case for all Android VoIP clients) because the audio delay is low. Which values are you using for echo tail and skew?

About AECM, we haven't tried it yet because the initial implementation based on WebRTC was for Windows and MAC OS X.

@boss, just to be sure, the echo you hear is the lack of cancellation on the other phone, in this case, the iPhone. If the other caller isn't complaining about echo, it is because your phone is canceling echo properly.

@ken : the iPhone has a true hardware echo canceller and from test results it is pretty good.

@mamadou : in CSipSimple, by default it use the speex echo canceller (for armv7), you have to change the echo canceller method in settings. To do so, you have to activate the expert setting mode (in settings, press menu and select expert mode, then in media settings choose the cancller mode to be WebRTC. You can also change the tail length). About skew, I use 0 for now. Do you have a suggestion for a better value?

I've seen that in doubango code you said that 16 and 32kHz produce weird results. On my side it does not sound so bad. What do you observe with doubango?

Also, in this case, I was wondering in this case what would be the best way to do : bufferFarend, process, bufferFarend, process or bufferFarend, bufferFarend, process, process

-- correction, build r995 was not build with webrtc available (my auto build script had not the option to build with webrtc), I'm currently running a new r995 build with webrtc inside :).

I have tried different providers and called and had callers with cell and land lines call me and in all cases, they hear an echo. Turning the sound down to where I can barely hear the caller does eliminate the problem. I also tried both 3g and wifi with the same results. I tested all of this with an Android 2.2 Samsung Galaxy Precedent.

Issue 1422 has been merged into this issue.

Issue 1255 has been merged into this issue.

csimple install� sur un Galaxy note ne fonctionne pas, abonn� sfr libertalk l'appel fonctionne mais il n'y a pas de son ni dans un sens ni dans l'autre.

Issue 1915 has been merged into this issue.

Issue 1915 has been merged into this issue.

I have a Nexus 4 running 4.2 that is rooted and unlocked running the stock ROM. I have calls setup to only use wifi with a business class comcast connect, or a 35/35mb frontier fiber connection at home. At either location the callees hear themselves and have a really bad echo after about .1 to .3 seconds after everything they say The only thing I have found that stops the echo completely is if I mute the mic in the dialer. If I turn down the speaker/earpiece volume to about 6-7 notches up that usually helps alot and the echo is not nearly as loud. I just loaded the march 5th nightly, and tried a few test calls which also had the echo. I have asked other Nexus 4 users some have the issue some do not. I have attempted countless configurations of echo canceling in the main section and the audio troubleshooting section. I think I have almost tried all the settings, and nothing makes any difference whatsoever. If I knew how to I would send you a log of what my settings are now and try to list some of the settings I have tried. If there are any suggested settings I should try I'm completely open to suggestions at this point. I really like the software and would love to get it working.

Issue 2226 has been merged into this issue.

I got a Nexus 4 (Android 4.2.2) and no matter how I configure the app, it just makes absolutely no difference (and I tried ALOT). I can hear myself even when making the built-in audio test. Echo lasts for about 0.5 s and is repeated 2-3 times. It's not usable at all for me. I'm giving up.

Select "Open-SL ES" -> "Java" and select WebRTC routing implementation and default WebRTC echo canceler mode.

Using Nexus 4, JB 4.3, sound quality is absolutely phenomenal. Here are the steps that work for me:

1. Reset audio to default settings.
2. Uncheck absolutely everything, even under the Audio Troubleshooting section.
3. Check: "IO Queue" and "Use mode audio api".
4. Force close application (seems to be needed to reinitialise settings).
5. Profit!

I can confirm this problem exists on the Nexus 5 for both the CSipsimple app and the native dialer.

Fix: In CSipSimple, settings > media > audio troubleshooting > audio mode for SIP calls > IN_Call

Completely fixes echo problems.