[Asterisk-Dev] False echo created by large read buffer in chan_zap.c

[Joel Daniels]

Greetings Asterisk Developers,
   We have been testing an Asterisk replacement to our existing phone system.
We have a Digium Quad T1 card going into a couple of channel banks, with FXS
cards connecting to a bunch of traditional analog phones.  Everything seemed to
work fine, except for a slight echo that was even audible between two stations!
When we called a station that had a really cheap phone the echo became
horrible.  The strange thing was that if two phones were in a meetme conference
there was no echo whatsoever.  We were so concerned about this problem that we
were considering aborting the whole project!
   However after several days of reading up on echo, we learned what you all
already know.  That echo exists on almost every call we make, but the delay is
normally so small that we hear it as healthy side-tone.  After plenty of code
reading (I love C) I found that meetme conferences rely on the zaptel driver to
actually do the mixing, and as a result two zaptel stations in a meetme room
will have almost no delay between them.  And sure enough when I tested one-way
delay, I found it to be audible during a normal bridged call, but inaudible
during a conference.  So at last I had the key, during a normal bridged call
there is a significant amount of one-way delay ( > 20ms).  So next I started
reading chan_zap.c until I found the following two lines:

    /* Chunk size to read -- we use 20ms chunks to make things happy.  */
    #define READ_SIZE 160

This was exactly what I had been looking for.  I changed READ_SIZE to 16 (2ms),
and all echo problems magically disappeared.  However unfortunately all voice
prompts sounded like a truck had run over the audio :-).  A bit more code
reading revealed that voice prompts are in the GSM codec which has an atomic
frame size of 160 samples, which is too large to fit into the zaptel's default
jitter buffer size of (4 READ_SIZE's).  So upping the "jitterbuffers" option in
zapata.conf to 40, restored prompts to normal playback.

This solution to echo is much better than an echo canceller when you can get
away with it.  This is because often echo will be generated on the far end of a
call, and under conditions out of your control.  So if you can decrease the
round trip delay to a minimum then you can let the human ear do all the echo
canceling (It is the beast hardware echo-can out there :-).

The only drawback to this solution, that I am aware of, is that CPU usage will
be higher, and real-time requirements will be much tighter.  Does anybody else
have any concerns with this solution?  We've only "smoke tested" it so far, but
it seems to work fine.

Also, if this is a reasonable echo solution, would there be any interest in a
patch that would make this option configurable.  It would simplify upgrade
procedures for us, and far more importantly, it would give other Asterisk users
a hint that zaptel latency can be reduced.  The patch should be very easy to
write, and if no one else wants to I'll be glad to write it.  If there is some
reason why this should not be a configuration option, then should the trick of
redefining it be posted on the wiki?

   Sincerely,
      Joel Daniels