Echo problems tracking issue

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by tdbj...@gmail.com on 31 Jul 2010 at 2:31

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 31 Jul 2010 at 4:40

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by dc3de...@gmail.com on 6 Aug 2010 at 1:46

[GoogleCodeExporter]

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. 

Original comment by k...@laberteaux.org on 15 Dec 2010 at 6:30

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 15 Dec 2010 at 7:05

[GoogleCodeExporter]

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. 

Original comment by Breaker...@gmail.com on 16 Dec 2010 at 4:31

[GoogleCodeExporter]

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

Original comment by ken.laberteaux on 19 Dec 2010 at 7:01

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 19 Dec 2010 at 7:19

[GoogleCodeExporter]

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?

Original comment by ken.laberteaux on 19 Dec 2010 at 8:26

[GoogleCodeExporter]

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

Original comment by ken.laberteaux on 19 Dec 2010 at 9:04

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 19 Dec 2010 at 9:49

[GoogleCodeExporter]

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?

Original comment by ken.laberteaux on 19 Dec 2010 at 9:58

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 19 Dec 2010 at 10:26

[GoogleCodeExporter]

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?

Original comment by ken.laberteaux on 21 Dec 2010 at 3:29

[GoogleCodeExporter]

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?

Original comment by r3gis...@gmail.com on 21 Dec 2010 at 3:49

[GoogleCodeExporter]

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?

Original comment by ken.laberteaux on 21 Dec 2010 at 4:21

[GoogleCodeExporter]

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/csips
imple/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 :) ). 

Original comment by r3gis...@gmail.com on 21 Dec 2010 at 6:11

[GoogleCodeExporter]

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.

Original comment by ken.laberteaux on 21 Dec 2010 at 8:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Issue 569 has been merged into this issue.

Original comment by r3gis...@gmail.com on 6 Jan 2011 at 7:53

[GoogleCodeExporter]

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

Original comment by ken.laberteaux on 6 Jan 2011 at 2:46

[GoogleCodeExporter]

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%2
Fapps%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?

Original comment by r3gis...@gmail.com on 6 Jan 2011 at 3:03

[GoogleCodeExporter]

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!

Original comment by ken.laberteaux on 6 Jan 2011 at 8:30

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 6 Jan 2011 at 8:47

[GoogleCodeExporter]

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?

Original comment by NameBran...@gmail.com on 7 Jan 2011 at 1:51

[GoogleCodeExporter]

@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

Original comment by r3gis...@gmail.com on 7 Jan 2011 at 11:20

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 23 Jan 2011 at 10:23

[GoogleCodeExporter]

What do you consider a big tail length?

Original comment by blujay...@gmail.com on 2 Mar 2011 at 8:09

[GoogleCodeExporter]

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.

Original comment by k...@laberteaux.org on 2 Mar 2011 at 9:49

[GoogleCodeExporter]

Issue 775 has been merged into this issue.

Original comment by r3gis...@gmail.com on 8 Mar 2011 at 10:06

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 13 Mar 2011 at 7:36

[GoogleCodeExporter]

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.

Original comment by rolf.leu...@gmail.com on 27 Mar 2011 at 2:27

[GoogleCodeExporter]

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

Original comment by tim.chip...@gmail.com on 1 May 2011 at 3:07

[GoogleCodeExporter]

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) 

Original comment by r3gis...@gmail.com on 1 May 2011 at 4:13

[GoogleCodeExporter]

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

Original comment by tim.chip...@gmail.com on 1 May 2011 at 8:08

[GoogleCodeExporter]

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

Original comment by tim.chip...@gmail.com on 1 May 2011 at 10:50

[GoogleCodeExporter]

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!

Original comment by k...@laberteaux.org on 4 May 2011 at 2:14

[GoogleCodeExporter]

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#setRoutin
g%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/csips
imple/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/csips
imple/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 :)

Original comment by r3gis...@gmail.com on 4 May 2011 at 9:30

[GoogleCodeExporter]

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

Original comment by k...@laberteaux.org on 4 May 2011 at 2:03

[GoogleCodeExporter]

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!

Original comment by jbr...@gmail.com on 4 May 2011 at 5:12

[GoogleCodeExporter]

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

Original comment by k...@laberteaux.org on 5 May 2011 at 10:20

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 7 May 2011 at 10:46

[GoogleCodeExporter]

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?

Original comment by k...@laberteaux.org on 10 May 2011 at 10:20

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 11 May 2011 at 8:24

[GoogleCodeExporter]

Issue 954 has been merged into this issue.

Original comment by r3gis...@gmail.com on 12 May 2011 at 8:34

[GoogleCodeExporter]

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

Original comment by jbr...@gmail.com on 23 May 2011 at 11:57

[GoogleCodeExporter]

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

Original comment by seo.siem...@gmail.com on 27 May 2011 at 10:46

[GoogleCodeExporter]

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.

Original comment by k...@laberteaux.org on 27 May 2011 at 4:15

[GoogleCodeExporter]

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?

Original comment by m...@mykohsu.com on 28 May 2011 at 5:55

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 28 May 2011 at 9:20