[Speex-dev] Re: aec

[Jean-Marc Valin]

> The solution is pretty straightforward -- just resample the audio data in
> real time using a reference clock.

I hope you're joking.

	Jean-Marc

> -----Original Message-----
> From: Jean-Marc Valin [mailto:Jean-Marc.Valin at USherbrooke.ca] 
> Sent: Friday, November 11, 2005 1:27 AM
> To: Duane Storey
> Cc: 'Jason Harper'; speex-dev at xiph.org
> Subject: RE: [Speex-dev] Re: aec
> 
> Le vendredi 11 novembre 2005 à 01:21 -0800, Duane Storey a écrit :
> > 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.
> 
> Then tough luck. There's just nothing that can realistically be done
> about it. It's not just the about Speex AEC. Every AEC will require
> inputs to be in sync and I doubt anyone is really going to spend a year
> (or likely more) of research trying to solve a problem that can
> otherwise be fixed by paying $20 for a non-braindead sound card.
> 
> 	Jean-Marc
> 
> > -----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
> > 
> > 
> > 
> 
> 
> _______________________________________________
> Speex-dev mailing list
> Speex-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
>