Hi Steve,<br><br>Have you read this paper?<br>(Heping Ding, David I. Havelock, Drift-Compensated Adaptive Filtering for Improving Speech Intelligibility in Cases with Asynchronous Inputs. EURASIP J. Adv. Sig. Proc. 2010:)<br>Let me call is paper-Drift.<br><br>It provided a method to evaluate Relative Sample Offset (RSO, d[i]) which is <br>omitted in the microsoft paper<br>(Challenges and Solutions for Designing Software AEC on Personal Computers)<br>Let me call is paper-Challenges.<br><br>The resampling in the paper-Drift is too coarse. Maybe we can combine the RSO<br>detection of paper-Drift to the paper-Challenges?<br><br>What's your opnion?<br><br>Maoquan<br><br>> I don't know if this has only recently been put on line, but I never <br>> noticed it until today - <br>> www.iwaenc.org/proceedings/*2008*/contents/papers/9044.pdf<br>> <br>> That paper is from people at MS describing, in some detail, what the <br>> Windows kernel echo canceller does to handle synchronisation issues. It <br>> tracks both time varying sample clock drift and hiccups in the sample <br>> streams. It seems to handle the drift in a fairly similar manner to the <br>> several other papers on the topic from the past 10 years.<br><br>It (Challenges and Solutions for Designing Software AEC on Personal Computers)<br>is a good paper. But some critical details were omitted. Let me have a summary.<br><br>1. The paper points out two phenomena which break the synchronization/alignment<br>of far-end signal and near-end signal. They are glitch (caused by loss of<br>samples) and clock drifting (caused by different clock generators).<br><br>2. It introduces a concept of Relative Sample Offset (RSO, d[i]). It indicates<br>the time drifting of relevant samples in far-end signal and near-end signal.<br>If no glitch and clock drifting, RSO (d[i]) will be constant. Glitch will make<br>it change suddenly whereas clock drifting will change it slowly and constantly.<br>So we can get the glitchs and clock drifting by monitoring the change of RSO.<br><br>BUT:<br>1. The paper gave some formulas to estimate clock drifting and glitchs in<br>chapter 3 from d[i] (RSO). But it did not told us how to get d[i].<br><br>2. It said there is another case which interferes the alignment. Who knows <br>what it is talking about?<br><br>"(3) Noisy timing measurements: Modern audio hardware provides timing data in order to<br>synchronize m[i] and s[i]. The information is always noisy, due to limited numerical<br>precision, data transfer delay, multithreading, etc."<br>m[i] is microphone signal after ADC, s[i] is speaker signal before DAC.<br><br>Maoquan<br><br>> <br>> Steve<br>> <br>> On 04/14/2011 07:26 PM, LiMaoquan2000 wrote:<br>> > Hi All,<br>> > Many Thanks to Underwood for her excellent review of our big trouble <br>> > which prevent LMS-based AEC algorithms to be used in most computer. <br>> > Maybe it can be summaried as follows:<br>> > 1. Different sample rate of sampling and rendering does exists in most <br>> > low-cost soundcards (In my experiments over more than 20 soundcards, <br>> > the differences range from 0.5Hz to more than 50Hz when sample rate is <br>> > set to 8000Hz). Maybe this is totally caused by hardware which can't <br>> > be solved by software settings.<br>> > 2. Static measurement of the difference between sample rates is far <br>> > from enough. Accurater measurement requires more time to record echo <br>> > signal in order to get accurater frequency shift from spectral <br>> > structure. However, the accuracy of the measurement is still limited <br>> > and not enough for long time work of AEC. For example, in my <br>> > experiment, I recorded 2^18/8000=32 seconds of echo signal, and the <br>> > freqency resolution is 8000Hz/(2^17)=0.0625Hz. With a precise <br>> > resampler (sinc interpolation), the speex AEC got much better <br>> > performance than before. But there are still audible residue echos <br>> > after AEC. Freqency resolution of 0.0625Hz is still far from enough. <br>> > There is still delay drift between near-end and far-end voice which is <br>> > caused by different sample rates even if it is largely eliminated by <br>> > the resampling. Moreover, the residue difference will cause overflow <br>> > or underflow of the buffer in a long time, which is a disaster to the <br>> > echo canceller.<br>> > Maybe this paper (Pawig, M., Enzner, G., and Vary, P., Adaptive <br>> > Sampling Rate Correction for Acoustic Echo Control in Voice-over-IP, <br>> > IEEE Transactions on Signal Processing, Vol. 58, No. 1, January 2010) <br>> > points out a correct direction. In this paper, the far-end signal is <br>> > resampled before send to AEC. It estimates the delay drift between <br>> > acoustic echo and estimated echo and adjusts step of sampling time. <br>> > When delay drift is zero, far-end signal after resampling will have <br>> > the same sample rate with the low-end signal. It seems perfect, but it <br>> > still have some weakness:<br>> > 1. If relies on a coarse initial convergence of the LMS filter to <br>> > estimate delay drift between acoustic echo and estimated echo. If <br>> > there is a big difference, such as 50Hz, no initial convergence can be <br>> > established.<br>> > 2. It is too slow to reach the balance. According to its experiment, <br>> > it will cost about 35-40 seconds to decrease the frequence difference <br>> > to 0Hz and ERLE will increase only when frequence difference is very <br>> > close to 0Hz. These results are under the environment without double talk.<br>> > Have GIPS and Microsoft some secret high efficient method? They AECs <br>> > converge very quickly, I could hardly hear any echo in the process. <br>> > How can they do it?<br>> > Maoquan<br>> ><br><br><br><br><span title="neteasefooter"><span id="netease_mail_footer"><hr>
<a href="http://mail.163.com/html/110414_attachment/att1.htm" target="_blank">体验网易邮箱2G超大附件，轻松发优质大电影、大照片，提速3倍!</a>
</span></span><br><br><span title="neteasefooter"><span id="netease_mail_footer"><hr/>
<a href="http://mail.163.com/html/110414_attachment/att1.htm" target="_blank">体验网易邮箱2G超大附件，轻松发优质大电影、大照片，提速3倍!</a>
</span></span>