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@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@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@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@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 ==> >
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@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of Jean-Marc Valin Sent: Friday, November 11, 2005 12:30 AM To: Jason Harper Cc: speex-dev@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@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@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@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@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@xiph.org http://lists.xiph.org/mailman/listinfo/speex-dev
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@xiph.org [mailto:speex-dev-bounces@xiph.org] On > Behalf Of Jean-Marc Valin > Sent: Friday, November 11, 2005 12:30 AM > To: Jason Harper > Cc: speex-dev@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@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@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@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@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@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev > > >
> 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 cancellationOn Win32, the proper solution is to use ASIO. This, unfortunately, requires a high end card. However, I've had some limited success using two identical soundblaster live cards, card A (mic) and card B (output card which samples speakers). On each event (sampling capture position passed a marker in the buffer): - Fetch hardware sample-accurate sampling position of card A and B as PosA and PosB. - Copy 320 samples from buffer of card A at offset WantPosA into "mic input". - Calculate "negative offset" SampOfs = PosA-WantPosA. - Copy 320 samples from card B at offset PosB-SampOfs into "speaker input". - WantPosA += 320 - Wait for next event and repeat. This means that even if the cards drift a little (and they do, even with identical cards), the drift is compensated for. Kind of. The downside of this "solution" is that it requires the ability to read the *hardware* sampling position at sample-accurate resolution, something few cards support (you can basically forget any kind of USB mic and most onboard soundcards). It works, but every 20 minutes or so the AEC gets confused and has to be manually reset. And while I don't have any "hard data" to back it up, it is my perception that users with ASIO (all sampled on one card with synchronous clock) get much better echo cancellation. PS: Unless it was made clear earlier; you don't need to sample the speakers unless you want to also cancel out sounds made by other programs. If all you want is to cancel out the sound of the "remote end", just feed the AEC the last frame you decoded and sent to the speakers.
Actualy, most sound cards I've used (including DSPs) support sample-accurate resolutions.. you might have to use diectsound on windows to get at it (as most companies don't focus as much on their winmm drivers anymore). Also, I'm not that familiar with ASIO, but if it's anything like kernel streaming, it has the end-user disadvantage of disconnecting the windows mixer from the sound card, which means they can only use audio in your application, and won't hear anything else on the system while it's running... -----Original Message----- From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of Thorvald Natvig Sent: Friday, November 11, 2005 10:01 AM To: speex-dev@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 cancellationOn Win32, the proper solution is to use ASIO. This, unfortunately, requires a high end card. However, I've had some limited success using two identical soundblaster live cards, card A (mic) and card B (output card which samples speakers). On each event (sampling capture position passed a marker in the buffer): - Fetch hardware sample-accurate sampling position of card A and B as PosA and PosB. - Copy 320 samples from buffer of card A at offset WantPosA into "mic input". - Calculate "negative offset" SampOfs = PosA-WantPosA. - Copy 320 samples from card B at offset PosB-SampOfs into "speaker input". - WantPosA += 320 - Wait for next event and repeat. This means that even if the cards drift a little (and they do, even with identical cards), the drift is compensated for. Kind of. The downside of this "solution" is that it requires the ability to read the *hardware* sampling position at sample-accurate resolution, something few cards support (you can basically forget any kind of USB mic and most onboard soundcards). It works, but every 20 minutes or so the AEC gets confused and has to be manually reset. And while I don't have any "hard data" to back it up, it is my perception that users with ASIO (all sampled on one card with synchronous clock) get much better echo cancellation. PS: Unless it was made clear earlier; you don't need to sample the speakers unless you want to also cancel out sounds made by other programs. If all you want is to cancel out the sound of the "remote end", just feed the AEC the last frame you decoded and sent to the speakers. _______________________________________________ Speex-dev mailing list Speex-dev@xiph.org http://lists.xiph.org/mailman/listinfo/speex-dev