#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: r3gis...@gmail.com

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

Owner: r3gis.3R
Status: Accepted

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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

[Anonymous]

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

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.

[Anonymous]

Originally posted by: ken.laberteaux

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

[Anonymous]

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

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 https://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 ;)

[Anonymous]

Originally posted by: ken.laberteaux

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?

[Anonymous]

Originally posted by: ken.laberteaux

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

[Anonymous]

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

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/structpjsuamediaconfig.htm

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

[Anonymous]

Originally posted by: ken.laberteaux

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?

[Anonymous]

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

Probably automatically computed :
[r472]

But I'm not sure

[Anonymous]

Originally posted by: ken.laberteaux

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

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

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

[Anonymous]

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

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?

[Anonymous]

Originally posted by: ken.laberteaux

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?

[Anonymous]

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

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 )
[r485]
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 :) ).

[Anonymous]

Originally posted by: ken.laberteaux

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.

[Anonymous]

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

Issue 569 has been merged into this issue.

[Anonymous]

Originally posted by: ken.laberteaux

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

[Anonymous]

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

I think that :
* [r564]
is the wrapper
* And the implementation of speex echo canceller comes from the speex third party :
https://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?

[Anonymous]

Originally posted by: ken.laberteaux

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!

[Anonymous]

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

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

[Anonymous]

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

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?

[Anonymous]

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

@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

[Anonymous]

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

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

You can now test [r590]. With speex echo mode and a big tail length; could help...