Open Source Echo Canceller Part 1


For the Free Telephony Project I have an embedded version of Asterisk running on hardware that supports several FXO and FXS ports. I need a line echo canceller that can handle echo on typical FXO and FXS ports. As a starting point I am using the echo canceller software included in the Zaptel device driver package.

However on my FXS and especially FXO ports, this echo canceller is not working too well. This seems to be a common problem with Asterisk using the the Zaptel echo canceller, and there is quite a lot of content on the web dealing with how to optimise the Zaptel echo canceller using various tweaks.

The Myth of Hardware Echo Cancellation

Currently, the best solution to echo is to use a “hardware” echo cancellation rather than the Zaptel “software” approach. Hardware echo cancellation uses DSP chips from companies like Octasic which contain embedded echo cancellation firmware. Several board manufacturers have added hardware echo cancellation as an extra price option. Of course, this “hardware” solution is really just proprietary DSP software that works better than the current Zaptel software.

One distinguishing feature of hardware echo cancellation is that it “just works”. When enabled, echo just goes away, apart from perhaps a second or two at the start of a call. Contrast this to the current Zaptel software echo canceller which often requires experimentation with many options, and in some cases cannot be made to work at all.

There is no fundamental reason why an echo canceller running in software cannot perform as well as a “hardware” echo canceller on a DSP chip. In fact, there are several advantages to a pure software approach such as simpler interfacing and lower cost. Why pay $400 – or thousands – (in the case of a few of the high end products) extra for “hardware” echo cancellation if your current PC can cancel echo at no extra cost? To prove this point Pika Technologies have implemented host based echo cancellers purely in software that work very well.

The real reason behind the myth of hardware based echo cancellers is the lack of an open source echo canceller that “just works”.


I must admit that I am no stranger to echo cancellation problems. I have worked on line echo cancellation several times over the past 15 years and have never really developed a canceller I was happy with. Like the Zaptel guys, I ended up with code that worked some of the time and needed a variety of tweaks and tricks like manual adjustment of gain parameters.

It’s a tough problem to develop a canceller that “just works” without lots of tweaking. I have a great deal of respect for the people who have worked on the Zaptel echo canceller, as I understand how hard it is to write this sort of software.

I would like to try a new approach. I want to get the open source community to help, rather than trying to solve the problem by myself. You can help by sampling your nasty echo problems and sending them to me. We can build a database of echo problems and use this to develop an improved algorithm.

I am also in contact with a few very bright DSP guys who are interested in helping. Unlike me, they have implemented successful line and acoustic echo cancellers in the past. So together I think we can develop an improved open source line echo canceller.

Getting under the Hood

To debug a program we need to look at it’s inputs and outputs. This is a little tricky with a real time echo canceller, as all the signals are processed in continuous streams. It’s not always possible to set a break point and look at the variables. So I have hacked the zaptel.c driver to sample the echo canceller signals and dump them to files. The idea is we can then look at the signals in the files and figure out what’s going on.

Here is the test set up:

The hybrid is an electronic gizmo that is part of your analog line interface hardware. It combines the separate transmit (tx) and receive (rx) signals onto one two-wire pair. In the receive direction, it’s job is to separate the combined tx rx signals and extract just the receive signal.

Lets say you transmit (tx signal) the words “ONE..TWO..THREE”. This gets sent down the phone line by the hybrid but a little bit gets reflected back “one..two..three” in the rx signal. This is the echo. In an ideal world no tx signal would get reflected back but due to real-world imperfections you always get a little (or a lot) of echo. The idea is that the echo canceller then cancels out the echo, leaving………silence (the ec signal).

So we have three signals going to/from the echo canceller:

  1. tx: the transmitted speech we are sending down the line (listen).
  2. rx: the received signal, which will contain the echo (listen).
  3. ec: the (hopefully) echo cancelled signal (listen).

If you listen carefully to the ec sample above you can hear the echo canceller slowly converging, by the time we get to “four” the echo level is significantly reduced.

So lets take a graphical look at the Zaptel echo canceller in action. Here is a plot of the words “one….two” from a FXO port connected to an Australian PSTN line. On the call I could clearly hear the echo of my own voice. Click on the image for a larger version.

You can get a feel for the performance of the echo canceller from this plot:

  1. The echo signal (rx) is quite a bit smaller than the transmit signal (tx). This is usually the case, unless your hybrid is way out.
  2. However look at the echo canceller output (ec). On the first word the level of this signal is about the same as rx (as the blue (ec) completely covers the green (rx)), which indicated not very much echo is being cancelled.
  3. It gets a little better on the second word, now the echo canceller has adapted to the echo a little, and the ec signal is at a slightly lower level than the rx signal. However this suggests the convergence of the echo canceller is slow, as it has not completely cancelled the echo yet.
  4. What we would like to see is the blue ec line to be completely flat – this would indicate that all the echo has been cancelled at the echo canceller output.

Sampling Echo Signals

The software to perform the sampling is called sample. Sample captures the real time echo canceller signals from a running Asterisk/Zaptel system to disk files. You can sample echo on an Asterisk system equipped with any zaptel compatible hardware. It works like this:

  1. Patch the zaptel driver as described in the README and start Asterisk.
  2. Using Asterisk set up a call through the FXO or FXS port you wish to sample. For example I set up a SIP-FXO call.
  3. Make sure there is no other receive signal on the line apart from the echo. For the FXO port I set up a dialplan to simply get an outside line “exten => 9,1,Dial(Zap/1)”, I then hit a DTMF key like 5 which causes the CO to stop the dial tone. For a SIP-FXS call I mute the phone on the FXS side.

When you are ready to start sampling:
[root@homework zaptel]# ./sample /xhome1/tmp/fxs 1 5
sampling Zap/1...
[root@homework zaptel]#

In this case it samples 5 seconds from Zap/1. While it is sampling I said “one..two..three….” into the SIP handset to generate the tx and rx signals. I could clearly hear echo coming back. Running sample generates the three sample files:
[root@homework zaptel]# ls /xhome1/tmp/fxs*
fxs_ec.raw fxs_rx.raw fxs_tx.raw

The files are in 16 bit signed short format, sampled at 8 kHz. You can listen to the samples on your sound card using the sox utility play:
# play -f s -r 8000 -s w fxs_tx.raw
If all is well the rx file should be quieter than the tx file. The ec file will be silent if your echo canceller is working, otherwise you will hear the uncancelled echo. You can plot your results you can using GNU Octave and the pl.m script:
octave:1> pl("/xhome1/tmp/fxs")
You can zoom in on certain parts of the waveform:
octave:6> pl("/xhome1/tmp/fxs",16000,20000)
which produced the plot below (again click on the image for a larger version):

In this case you can see the echo canceller is doing a better job. In the second half of the word the blue (ec) line is very thin, showing that the echo has been cancelled. The first half is not so good, once again the blue ec is overwriting the green rx indicating poor cancellation. The first half of this word (the “t” sound in “two”) consists of a noisy waveform, this has significant high frequency content. This suggests the echo canceller hasn’t converged as well for high frequencies as it has for low frequencies.

The cool thing about sampling this way is that it doesn’t interfere with your running Asterisk system. If you hear echo at any time you can fire up a console and run “sample” to capture real-time data from the Zaptel port.

Next Steps

Next I would like to write a command line program to run the Zaptel echo canceller in non-real time, using the sampled tx & rx files as inputs. This simulation version of the echo canceller will be easier to work with compared to running the same code in real time. For example we can set breakpoints, stop/start at will, and dump internal states to files for further analysis.

If you would like to help develop an open source echo canceller, please collect some samples and send me you echo samples! I would welcome any samples of your echo signals, for example where the echo canceller isn’t working well, and also cases where it does work well. By comparing the two cases we can learn a lot about the strengths and weaknesses of the algorithm.

Please name the sample files in a way that is unique, for example if your name is Charlie Brown “fxs_charlie_brown_line_1_tx.raw” and email the files to me.

Reading Further

The Open Source Line Echo Canceller (Oslec) has progressed a great deal since this initial (Part 1) post was written:

Oslec Home Page
Part 2 – How Echo Cancellers Work
Part 3 – Two Prototypes
Part 4 – First Calls
Part 5 – Ready for Beta Testing


Thanks Mike Taht and Wojciech Tryc for helping me with this work and blog post.
auto after loan bankruptcyloan ahard moneyloan mortgage alabama secondhome loans mortgage alaskaloan american dream homereport $1000 loanloan personal 000 10100 rv loans Maptorrent porn sites bitwork pornsite at bitchesporn bitingpirates porn bittorentporn bittorrent andporn search bittorrentbizar porn trailersadult pornography bizarre Mapbest rates loan constructionbest loan home interest equity rateshome washington rates best loanfor best home rate loans interestpoor places with loan credit bestlowest best rates possile loan autofor loan best car rateroadloans business bureau better Mapvideo devon pornporn free devon vidsvideo free devon pornstarporn dhakadhild images pornagraphydia star pornblack porn star diamondporn diamond MapBuy CarisoprodolAdderall OrderPurchase HydrocodoneCheap ProvigilPhentermine CheapNo Clonazepam PrescriptionCheap Online PhentermineVicodin DiscountPurchase NorvascEffexor Cheap Map

4 thoughts on “Open Source Echo Canceller Part 1”

  1. Hi there David
    i really dont know how to start but as i read thru your blog comment about the ideal for the low cost of telephony in the developing countries, the first thing came into my mind is that we really need to support such an ideal because for we have almost three years working on asterisk try to find a solution that bring low cost telephony to remote areas and rurals location in my country , by the way i’m from vietnam and we haven’t really found one since the hardware cost are quite expensive if using traditional digium hardware and a small and flexible system .B ut with your project i strongly belive that one day the basic of our modern world will be realistic for those people in the remote areas , please kindly advise us that how can we donate for your project . Thank you for reading this.
    kindly regards

  2. Hi Phuc,

    One thing you could help me with is some “market research”. You see I
    want to make sure that I am building the right technology for the needs
    of the developing world. So pls tell me what you ideal VOIP “product”
    would look like, based on your needs.

    For example:

    + number and type of ports (FXS/FXO/BRI)
    + cost
    + price
    + power supply
    + any other useful features (wireless, solar battery controlling, ease
    of use etc)

    My goal for ealy next year is to take some of the components we have developed and designs a 4-port (FXO or FXS) PBX that can be built in small quantities for US$200. But I need guidance from people in the developing world to help design the “right product”.

    Another challenge is two work out a way to manufacture in volume – this will reduce the price further.

    BTW pls feel free to email me direct, my email address is on my main web site.



  3. Hi David,

    Thanks for the excellent article.

    One of the things that would make your small PBX stand out from the rest, is having an operator panel (think of FOP) available right out of the box.
    From experience in the field, we see that the lack of such a panel (and the inability to install or run it) on the current embedded linux/asterisk projects, is one of the main reasons that even in small setups with only 2 FXO lines, people still have to go with a standard pc for their PBX, although an embedded device would be a much nicer solution…

    So if I may give you a good piece of advice: make sure that FOP (or something equivalent) can run on your system, and there will be a great deal of interest in your project!!

    Kind regards,

  4. Pingback: » echo

Comments are closed.