So any software echo canceller available in dahdi isn't good enough?<br><br><div class="gmail_quote">2011/9/13 Kevin P. Fleming <span dir="ltr"><<a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On 09/13/2011 08:56 AM, Gustavo Santos wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm trying to use Asterisk as a PSTN simulator to run performance tests<br>
for echo cancellation algorithms. I'm using the following configuration:<br>
<br>
SIP <-----> Asterisk 1 <----> Asterisk 2 <----> Echo()<br>
<br>
Asterisk 1 and Asterisk 2 are connected using E1. Echo() is the dialplan<br>
application.<br>
<br>
The problem is the high delay using this configuration: 20 ms only in<br>
Asterisk 2. I've read the source code of chan_dahdi, and I think the<br>
channel has a 20 ms "buffer" (160 samples). Algorithms like mg2 and kb1<br>
are configured to accept 128 taps (16 ms), so 20 ms is too high.<br>
<br>
Someone knows how I can reduce the delay to at least 10 ms? Should I<br>
change something in the source code?<br>
</blockquote>
<br></div></div>
20 milliseconds is far from a 'high' (long) delay. Asterisk handles audio in packets, it does not directly switch TDM streams. As a result, there is always going to be (at least) the delay of one packet time for audio passing into Asterisk and back out via the Echo() application. This is unavoidable.<br>
<br>
An alternative solution would be to send a call into Asterisk2 and have it dial back to Asterisk1 (and then back to the originating endpoint) and bridge those two calls in Asterisk2; if both calls are on the same E1, then Asterisk will let the DAHDI hardware directly connect the two channels, resulting in a 1 or 2 millisecond delay.<br>
<br>
But realistically... configuring an echo canceller with only a 16ms window of operation is not very practical. Sending a call through *any* network element that packetizes the audio will result in a delay longer than 16ms.<br>
<br>
-- <br>
Kevin P. Fleming<br>
Digium, Inc. | Director of Software Technologies<br>
Jabber: <a href="mailto:kfleming@digium.com" target="_blank">kfleming@digium.com</a> | SIP: <a href="mailto:kpfleming@digium.com" target="_blank">kpfleming@digium.com</a> | Skype: kpfleming<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
--<br>
______________________________<u></u>______________________________<u></u>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-<u></u>users</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Atenciosamente,<div>Gustavo Santos.</div><br>