[Speex-dev] Anyone knows how microsoft AEC can deal with mismatches between clocks of capture and render streams?

[Steve Underwood]

On 04/13/2011 02:58 AM, Shridhar, Vasant wrote:
> I am doing this right now with no problem.  I am not using speex for this at the moment though.  Group delay is the biggest problem.  I implemented a version where the input and output sample rates are known up front.  The routine than interpolates between the jitter.  This should solve the problem.  The crystals used to clock the input and output have very fine tolerances on most standard audio cards.
Do you mean the group delay of your interpolation filter? I don't see
why that is an issue. At the echo cancellation point it just looks like
a bit more echo delay. I also don't know why you use the word jitter in
relation to interpolation. The jitter you have is in the reception time
of blocks of samples, which makes the assessment of sampling rates hard,
but doesn't affect the actual interpolation.

We are talking about two clocks, which are not synchronised, and which
may drift in frequency significantly over fairly short periods of time.
The issue is accurately assessing the sampling rate difference, to phase
locked levels of accuracy, so the resampling is precise. You can find
sampling rates like 8000/s and 8100/s, which is a disaster for most echo
cancellers. If the clock rate difference is assessed to 0.1Hz accuracy,
and the 8100/s sampled signal is resampled to 8000.1/s, you would still
need to totally readapt the canceller every 10s, including periods of
double talk. That is too fast for the canceller to ever be working well.
You really need a very accurate assessment of the sampling rate
difference, so you can essentially eliminate all difference between the
two rates.

Assessing the sampling rate difference accurately is not hard, if you
have plenty of time. Doing it in a shorter period is where the challenge
lies. You are decoupled from a precise real time view of the sampling
process. All you can base your sampling rate assessment on is long term
assessments of sample rates, or an analysis of how the echo is drifting
through the samples. From the last 10 years you will find a number of
papers published in IEEE and other journals about this problem, as it
pertains to echo cancelling in conferencing, and other distributed
setups. In these systems, synchronisation of various echo laden signals
is impractical. All the papers I've seen come down to doing basically
the same thing - resampling based on a best assessment of echo drift
rates. It seems like its still a research topic, and it seems like
existing solutions have their problems. Fraunhofer have recently
released a conferencing echo handler with a vague description of how it
works, but a clear indication that it isn't even trying to cancel the
echo. It is juggling gains, and performing other tricks, to make the
echo perceptually tolerable - an approach which has historically worked
pretty well (e.g. the DSP Group solution from the 90s). At least one
person reported, on this list, that their solution is the best around.
> Vas
> ________________________________________
> From: Li Maoquan [limaoquan2000 at 126.com]
> Sent: Tuesday, April 12, 2011 2:48 PM
> To: Shridhar, Vasant
> Cc: speex-dev
> Subject: Re:RE: [Speex-dev] Anyone knows how microsoft AEC can deal with mismatches     between clocks of capture and render streams?
>
> Hi Shridhar,
>
> Sample rate conversion is not enough to solve this problem. I have tried this method several months
> ago. The first step is to measure the difference between sample rate of capturing and rendering. Then
> resampling (by what you said "sinc interpolation") one signal to eliminate the difference. The frequency
> step in my experiment is less than 0.1Hz. I have tried speex AEC after resampling, much more echo is
> cancelled than the one without resampling. But there is still echo can be heared.
> After all, frequency step of sample rate conversion is limited, mismatch is still exist after resampling.
> Someone told me that capture and render codec have different clock generator which shift independently.
> And LMS algorithm is very sensitive to the difference between sample rates.
>
> Sincerely
> Maoquan
>
> At 2011-04-12 21:46:26，"Shridhar, Vasant" <vasant.shridhar at harman.com> wrote:
> I would imagine that it is handle through basic asynchronous sample rate conversion.  There is a lot of literature out there on the different techniques to do this.  A common method is sinc interpolation.  This is how I have handle these types of things in the past.
>
> Vasant Shridhar
>
> From: speex-dev-bounces at xiph.org<mailto:speex-dev-bounces at xiph.org> [mailto:speex-dev-bounces at xiph.org<mailto:speex-dev-bounces at xiph.org>] On Behalf Of LiMaoquan2000
> Sent: Tuesday, April 12, 2011 12:36 AM
> To: speex-dev
> Subject: [Speex-dev] Anyone knows how microsoft AEC can deal with mismatches between clocks of capture and render streams?
>
>
> Hi all,
>
> We all know that mismatch between clocks of ADCs of far-end voice and near-end voice is not allowed in a time-domain or frequency-domain LMS based AEC system. It means that capture and render audio streams must be synchronized to a same sample rate. However, I found that this restriction is removed in microsoft AEC from Windows XP SP1. Anyone knows how microsoft AEC do it? This technology is much helpful for us to implement AEC in common PC. We know that most low-cost soundcards have different sample rates in capturing and rendering which prevents LMS based AEC from being used in most computer.
>
> http://msdn.microsoft.com/en-us/library/ff536174(VS.85).aspx<http://msdn.microsoft.com/en-us/library/ff536174%28VS.85%29.aspx>
> In Windows XP, the clock rate must be matched between the capture and render streams. The AEC system filter implements no mechanism for matching sample rates across devices. ............. In Windows XP SP1, Windows Server 2003, and later, this limitation does not exist. The AEC system filter correctly handles mismatches between the clocks for the capture and render streams, and separate devices can be used for capture and rendering.
>
You have posted the same thing before, but ignored replies because you
didn't like them. The paragraph you quoted can be taken as a clear
statement that MS precisely resample the signals. However, if you read
the whole page it is less clear. The key thing that paragraph is talking
about is big sampling rate changes - like taking a 48k/s signal and a
16k/s signal, and resampling the 48k/s one to 16k/s, so cancellation can
work. That is the thing which seems to have been added in XP SP1. The
paragraph seems to imply that fine resampling happens, but if you read
the rest of the page it comes from, things are not so clear. There are
many vague and unclear things on that page. If they had brilliantly
solved this problem, everyone should be relying on the MS canceller for
their Windows solutions, but that doesn't seem to be the case. It seems
many soft-phones rely on their own echo handling solutions, and many do
not handle echo very well.

Steve