[Speex-dev] Re: aec

Fri Nov 11 01:21:12 PST 2005

This is a very real problem though.. I've encountered many sound cards that
use different clocks for input and output (even on the same card!) Also, if
you open up a sound device on windows at 8kHz, the microphone is often
around 8100Hz, while the output is 8000Hz.. I'm not sure if there's a bug
somewhere in some of the OS resampling algorithms, but I've seen that on
many machines.

-----Original Message-----
From: speex-dev-bounces at xiph.org [mailto:speex-dev-bounces at xiph.org] On
Behalf Of Jean-Marc Valin
Sent: Friday, November 11, 2005 12:30 AM
To: Jason Harper
Cc: speex-dev at xiph.org
Subject: Re: [Speex-dev] Re: aec

To everyone on the list: do *NOT* attempt to do echo cancellation with
signals sampled using different clocks. This will *NOT* work. Just a
0.1% difference between the two sampling rates (it's sometimes worse
than that) means that the impulse response drifts by 8 samples every
second. There's just no way to efficiently track this.  Or at least no
way that doesn't involve something 100x more complex than what I have
now. So if you want to use two different soundcards, you should either:
1) Have professionals cards connected with a clock sync
2) Have an atomic clock in both cards
3) Forget about echo cancellation

	Jean-Marc

Le jeudi 10 novembre 2005 à 22:54 -0800, Jason Harper a écrit :
> Thanks for taking a look.  There was no motion;
> however you are right about sampling from a different
> card.  The speaker is connected to the Sound Blaster
> card, while the microphone is part of a USB webcam.  I
> don't think that this is likely to be too unusual a
> configuration among users.  
> I can retry the test using a sound card microphone to
> see if there is a difference.  If it turns out that
> the problem is due to using different sound devices
> for speaker and microphone, does this mean that the
> mdf algorithm is particularly sensitive to the clock
> drift between devices?  Is this because the
> frequencies of the two signals would be slightly off,
> reducing the correlation of the two signals?  Any
> suggestions on how the algorithm could be tweaked to
> lessen this problem?
> 
> -Jason
> 
> --- Jean-Marc Valin <jean-marc.valin at usherbrooke.ca>
> wrote:
> 
> > Had a try. The reason why a simple delay is not that
> > good is mainly due
> > to the initialization of the filter parameter that
> > still takes a few
> > seconds (if they are perfectly in sync, you sort of
> > get lucky).
> > Otherwise, you real recording seems to have
> > something odd in it. Are you
> > sampling from a different card then the one that's
> > playing the sound? or
> > maybe the mic (or something else) in the room is
> > moving while you're
> > recording?
> > 
> > 	Jean-Marc
> > 
> > 
> > On Thu, 2005-11-10 at 07:28 -0800, Jason Harper
> > wrote:
> > > When I ran test 4 as originally described there is
> > > substantial echo cancellation (but not as good as
> > when
> > > the files are perfectly aligned).  When I invert
> > the
> > > inputs, there is no noticeable cancellation.
> > > I'm using testecho with the preprocess line
> > commented
> > > out.  Preprocess seems to work very well at
> > cleaning
> > > up the residual echo when mdf does its job, so I'm
> > > just focusing on testing mdf.
> > > 
> > > -Jason
> > > 
> > > --- Jean-Marc Valin
> > <Jean-Marc.Valin at USherbrooke.ca>
> > > wrote:
> > > 
> > > > First try your test #4 (same signal and offset)
> > and
> > > > swap the inputs.
> > > > 
> > > > 	Jean-Marc
> > > > 
> > > > Le mercredi 09 novembre 2005 à 22:44 -0800,
> > Jason
> > > > Harper a écrit :
> > > > > I'm pretty much sure of it.  When I test
> > inverting
> > > > the
> > > > > inputs, my output is pretty much the same as
> > my
> > > > > speaker signal.  Whereas the way that I
> > normally
> > > > test
> > > > > the output is my mic signal with very little
> > > > > attenuation.
> > > > > If you are interested I can send my test
> > files;
> > > > they
> > > > > are about 94KB each.
> > > > > 
> > > > > -Jason
> > > > > 
> > > > > --- Jean-Marc Valin
> > > > <jean-marc.valin at usherbrooke.ca>
> > > > > wrote:
> > > > > 
> > > > > > Are you sure you're not just inverting the
> > two
> > > > > > inputs?
> > > > > > 
> > > > > > 	Jean-Marc
> > > > > > 
> > > > > > On Wed, 2005-11-09 at 22:16 -0800, Jason
> > Harper
> > > > > > wrote:
> > > > > > > I ran some further tests on mdf and here
> > are
> > > > the
> > > > > > > results:
> > > > > > > 1. reduced tail length to 100ms, aligned
> > mic
> > > > and
> > > > > > > speaker signals to within 10ms - almost no
> > > > echo
> > > > > > > attenuation
> > > > > > > 2. aligned mic and speaker signals to
> > within 5
> > > > > > samples
> > > > > > > - still almost no echo attenuation
> > > > > > > 3. ran testecho using the same file for
> > mic
> > > > and
> > > > > > > speaker - very good echo cancellation (of
> > > > course
> > > > > > this
> > > > > > > is expected, but I needed to do a sanity
> > > > check)
> > > > > > > 4. ran the same file for mic and speaker,
> > but
> > > > had
> > > > > > the
> > > > > > > mic signal delayed by 10ms - OK echo
> > > > cancellation,
> > > > > > but
> > > > > > > noticeably degraded over previous test
> > > > > > > 5. same file for mic and speaker, but mic
> > > > signal
> > > > > > > delayed by 40ms - noticeable echo
> > attenuation,
> > > > but
> > > > > > > still a large echo.
> > > > > > > 
> > > > > > > So far my testing is only showing good
> > echo
> > > > > > > cancellation when the exact same file is
> > being
> > > > > > used
> > > > > > > and is pretty closely aligned.
> > > > > > > 
> > > > > > > -Jason
> > > > > > > 
> > > > > > > --- Jean-Marc Valin
> > > > > > <Jean-Marc.Valin at USherbrooke.ca>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > This kind of behaviour is odd. One of
> > the
> > > > reason
> > > > > > > > could be the fact that
> > > > > > > > you're using a really long impulse
> > response.
> > > > Try
> > > > > > > > syncing your signals
> > > > > > > > and making the tail length more in the
> > order
> > > > of
> > > > > > 100
> > > > > > > > ms to 300 ms.
> > > > > > > > 
> > > > > > > > 	Jean-Marc
> > > > > > > > 
> > > > > > > > Le dimanche 06 novembre 2005 à 21:25
> > -0800,
> > > > > > Jason
> > > > > > > > Harper a écrit :
> > > > > > > > > Thanks for alerting me to the new
> > changes.
> > > >  I
> > > > > > just
> > > > > > > > > tried the latest code from SVN, but
> > > > > > unfortunately
> > > > > > > > I
> > > > > > > > > still have just about the same
> > results. 
> > > > The
> > > > > > > > estimated
> > > > > > > > > echo that gets subtracted from the
> > actual
> > > > echo
> > > > > > is
> > > > > > > > such
> > > > > > > > > a small signal that it doesn't really
> > > > result
> > > > > > in
> > > > > > > > any
> > > > > > > > > noticeable echo attenuation.
> > > > > > > > > I currently have my filter size set to
> > 2
> > > > > > seconds
> > > > > > > > even
> > > > > > > > > though the echo in my microphone file
> > is
> > > > only
> > > > > > > > about
> > > > > > > > > 180ms delayed from the signal in my
> > > > speaker
> > > > > > file. 
> > > > > > > > I
> > > > > > > > > also double checked that the endianess
> > of
> > > > my
> > > > > > is
> > > > > > > > > correct, and that I am providing the
> > files
> > > > to
> > > > > > > > testecho
> > > > > > > > > in the correct order.
> > > > > > > > > Do you think that there could be some
> > > > > > > > characteristics
> > > > > > > > > to my echo that make it not work with
> > the
> > > > mdf
> > > > > > > > > algorithm?  How much echo attenuation
> > > > should I
> > > > > > > > expect
> > > > > > > > > from the mdf algorithm before the
> > > > preprocess? 
> > > > > > Are
> > > > > > > > > there any test speaker and mic files
> > that
> > 
> === message truncated ===
> 
> 
_______________________________________________
Speex-dev mailing list
Speex-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/speex-dev