<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=GB2312">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.6603.0">
<TITLE>Re: [asterisk-dev] Suggestion on Packet Loss Concealment Algorithm</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hi,</FONT></SPAN>
</P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">The theory is not based on the music, it's based on that given by the ITU G.711 Appendix I (BTW: the music is converted to 8K/mono/16bit by CoolEdit).</FONT></SPAN></P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">And the current plc algorithm is similar to the G.711 Appendix I except:</FONT></SPAN>
<BR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">1. The pitch detection algorithm : G.711 Appendix I uses cross correlation, but Asterisk uses AMDF which is simpler and also performs well</FONT></SPAN></P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">2. The OLA window: G.711 update the OLA window length when burst loss occurs, but Asterisk didn't</FONT></SPAN>
<BR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">3. The nearby field of the first erasure: G.711 delays the output for 3.75 ms to compensate the probable loss, but Asterisk just use the symmetrical</FONT></SPAN></P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">part before the lost to do the OLA. The one G.711 Appendix I utilized should be better, but it's not very important as human being's ears are really anti-jamming.</FONT></SPAN></P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">4. whether prolong the pitch period during burst loss: G.711 Appendix I prolong the pitch period to a maximum of 3 pitch period, but Asterisk only uses one which</FONT></SPAN></P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">saves memory but behave bad at burst loss.</FONT></SPAN>
</P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">BTW:</FONT></SPAN>
<BR><SPAN LANG="en-us"> <FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Not only in my experimentation but also in some book, you can find the theory that the quasi-periodic voice's cycle should not last very long (As for the</FONT></SPAN></P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">file i use, it's about 15ms), and the first part are produced by the pitch detection algorithm, in this case both G.711 and Asterisk behave well. It's just whether prolong</FONT></SPAN></P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">the pitch period make them different. And because the experiment show that the concealed output of G.711 Appendix I contains a lot of phase mismatch and amplitude</FONT></SPAN></P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">mismatch, so it means that how to produce the prolonged pitch is not very strictive, that's why i just simply prolong it and not utilize the algorithm like G.711.</FONT></SPAN></P>
<P><SPAN LANG="en-us"> <FONT COLOR="#0000FF" SIZE=2 FACE="Arial">And believe me, before i report it formally i will test it will samples from sources like MOCHA.</FONT></SPAN>
<BR><SPAN LANG="en-us"> <FONT COLOR="#0000FF" SIZE=2 FACE="Arial">The original attachment is a working demo (the utility of ITU STL2005 could be downloaded for free, which also named ITU G.191),</FONT></SPAN></P>
<P><SPAN LANG="en-us"> <FONT COLOR="#0000FF" SIZE=2 FACE="Arial"> so if you want to prove me wrong, please show me the source file you use and i'd be very glad to improve.</FONT></SPAN><SPAN LANG="zh-cn"></SPAN><SPAN LANG="zh-cn"></SPAN>
</P>
<P><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Sincerely,</FONT></SPAN>
<BR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Colin</FONT></SPAN><SPAN LANG="zh-cn"></SPAN><SPAN LANG="zh-cn"></SPAN>
<UL>
<P><SPAN LANG="zh-cn"><FONT FACE="宋体"></FONT></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="宋体">-----原始邮件-----</FONT></SPAN>
<BR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="宋体">发件人: </FONT></B> <FONT SIZE=2 FACE="宋体">asterisk-dev-bounces@lists.digium.com [<A HREF="mailto:asterisk-dev-bounces@lists.digium.com">mailto:asterisk-dev-bounces@lists.digium.com</A>] </FONT><B> <FONT SIZE=2 FACE="宋体">代表</FONT></B> <FONT SIZE=2 FACE="宋体">Steve Underwood</FONT></SPAN></P>
<P><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="宋体">发送时间: </FONT></B> <FONT SIZE=2 FACE="宋体">2006年5月18日 21:38</FONT></SPAN>
<BR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="宋体">收件人:</FONT></B> <FONT SIZE=2 FACE="宋体">Asterisk Developers Mailing List</FONT></SPAN>
<BR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="宋体">主题: </FONT></B> <FONT SIZE=2 FACE="宋体">Re: [asterisk-dev] Suggestion on Packet Loss Concealment Algorithm</FONT></SPAN>
</P>
<BR>
<P><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">ColinZuo@viatech.com.cn wrote:</FONT></SPAN>
</P>
<P><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> Hi all,</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">></FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> The current PLC algorithm uses only one pitch period, and therefore</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> behaves bad during burst lost (Beeps in background),</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">></FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> I have prolonged the pitch period under burst loss situation and</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> tested it using a small utility of ITU STL2005. As for the music files</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">></FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> (which were produced using VLC's file output module), the modified plc</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> can handle 50% and 50ms long loss, although it might be that</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">></FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> the music wave doesn't vary very fast, i think the modification still</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> improve the performance very much.</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">></FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> The attachment is the rar of the modified files, very little change</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> <<asteriskplc.rar>> .</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">></FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> Sincerely,</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">> Colin</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">></FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">This sounds like a really bad idea. The current PLC algorithm isn't</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">designed for music. It is designed for voice. From your description it</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">sounds like you don't actually understand what the current code is doing.</FONT></SPAN>
</P>
<P><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">Steve</FONT></SPAN>
</P>
<P><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">_______________________________________________</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">--Bandwidth and Colocation provided by Easynews.com --</FONT></SPAN>
</P>
<P><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">asterisk-dev mailing list</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体">To UNSUBSCRIBE or update options visit:</FONT></SPAN>
<BR><SPAN LANG="zh-cn"><FONT SIZE=2 FACE="宋体"> <A HREF="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</A></FONT></SPAN>
</P>
</UL>
</BODY>
</HTML>