similar to: About Sampling Rate Correction in acoustic echo

I can only evaluate this with my subjective point of view. I had a special test scenario doing chat with cheap webcam microphones and loudspeakers. Fraunhofers solution was the only one that could eliminate the echo. In double talk the quality gets lower but is still very good. You might want to ask Fraunhofer for a demo version to test for yourself. I have no details on the algorithms being

Hi all, We have discussed so many about sampling rate asynchronous (or offset) between rendering (D/A converter) and capturing (A/D converter) of most PC soundcards. It seems all acoustic echo cancellers, include AEC in speex, can not deal with this trouble, because it causes a drift of echo path and also buffer overflow and underflow which jumps the delay of echo path seriously. Unfortunately,

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

On 01/20/2011 04:26 AM, Steve Underwood wrote: > On 01/19/2011 06:44 PM, LiMaoquan2000 wrote: >> Hi all, >> >> We have discussed so many about sampling rate asynchronous (or offset) >> between rendering (D/A converter) and capturing (A/D converter) of >> most PC soundcards. It seems all acoustic echo cancellers, include AEC >> in speex, can not deal with this

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

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

>> There is also a IEEE paper, Adaptive Sampling Rate Correction for >> Acoustic Echo Control in Voice-Over-IP, which introduced a complex >> method to estimate the frequency offset and resynchronize the signals >> using arbitrary sampling rate conversion. I wonder if it can provide >> enough performance. Because I have also designed a sampling rate >>

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

Then why ONE sound card have different capture and playback rate? It must be ONE single physical clock generator which is used by both ADC and DAC in the sound card, isn't it? If you are a hardware engineer. Will you design two different physical clock for ADC and DAC seperately? What on earth causes this problem? Who knows its intrinsic real reason? Isn't there any other solutions? For

>>>> Hi, >>> >>> I have a scenario in a mobile VoIP app that requires echo cancellation but >>> is somewhat different from what's described in the docs. >>> >>> Audio is received from and sent to the network at 8000Hz. Each packet >>> contains 160 samples worth a playback of 20ms. >>> >>> But the hardware

Simply to say, in a quiet room, you can play a impulse signal and then find it's impulse response signal from the microphone. For example, if the delay between the impulse signal and its response signal range from 500 to 3000 cycles, you can buffer the far-end signal to 0-300 cycles and set the filter length to 4000. It is also called to align far-end signal and near-end signal. BTW: Speex

Hello Jean-Marc, I solved the variable delay problem, but I still have trouble with speex_echo_cancel(). When i try testecho.c with clean speech for far-end input and same speech with attenuation, a bit of reverb and 50-150 ms delay, all this done in sound editor, for mic input, i get 5-8 db attenuation. But when i use the same speech played and recorded for mic input, i see about 5 db of

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 >

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

Hi everyone, I've just released Speex 1.1.9. The main change in this release is the echo canceller work sponsored by Tipic Inc (http://www.tipic.com/). It is now possible to do acoustic echo cancellation and obtain good attenuation after a short adaptation time. This has been tested at 8 kHz, but it should also work at 16 khz and above, so give it a try. There were also some fixes to the

Hi All, Many Thanks to Underwood for her excellent review of our big trouble which prevent LMS-based AEC algorithms to be used in most computer. Maybe it can be summaried as follows: 1. Different sample rate of sampling and rendering does exists in most low-cost soundcards (In my experiments over more than 20 soundcards, the differences range from 0.5Hz to more than 50Hz when sample rate is set

2011/4/20 Li Maoquan <limaoquan2000 at 126.com> > Simply to say, in a quiet room, you can play a impulse signal and then find > it's impulse response signal from the > microphone. For example, if the delay between the impulse signal and its > response signal range from 500 to > 3000 cycles, you can buffer the far-end signal to 0-300 cycles and set the > filter length

I've tried some further debugging to see what mdf is actually doing. Instead of sending: tmp_out = (float)ref[i] - st->y[i+st->frame_size] to the output, I just sent st->y[i+st->frame_size] to see what was being subtracted from the microphone input. When I open this in Audacity, I see a very small signal at about -40dBm. The actual echo in my sample has a power closer to -20dBm.

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.

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