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

[Paradise Dove]

I suggest you to open a bug on http://bugs.digium.com
and put the patch there

btw, this solution seems cool. 

Paradise Dove


On Fri, 19 Nov 2004 12:39:36 -0600, Joel Daniels <joeld at invtools.com> wrote:
> 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
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>