similar to: echo cancellation for analog lines

Hello, I am testing speex 1.1.6's echo canceller. I am using testecho.c, with a few modifications to get it to run on Windows. My problem is that I am unable to get the echo cancellation to work correctly. I am working on an audio conferencing software, and one issue we have is sometimes the microphone picks up what is being played through the headset, resulting in an echo of the other

Hi, On Tue, Aug 24, 2004 at 10:44:49AM -0700, Shana Cooke (Gitnick) wrote: > The result has my husband speaking clearly, but the echo of myself > talking is garbled and sounds like the Borg Hive from Star Trek. It's > more distracting than the original signal was. I have tried introducing > delays to my echo, but it does not help the signal to become clearer. Try this patch. It

Hi I just upgraded to http://svn.xiph.org/trunk/speex r10357 and got this build warning: alfredh@io:$ make -s mdf.o libspeex/mdf.c: In function 'speex_echo_cancel': libspeex/mdf.c:321: warning: statement with no effect libspeex/mdf.c:317: warning: `adapt_rate' might be used uninitialized in this function Is this intentional? In any case here is a simple fix: Index:

Current SVN compilation fails on Win32 (Intel C++ compiler 9.0): ..\..\libspeex\mdf.c(317): error: declaration may not appear after executable statement in block float adapt_rate; Just moved it up to the variable declaration block to solve it locally, but as it's not valid C, I thought I'd mention it ;) PS: With the same compiler, AGC fails horribly (Zlast goes to several

Hi Ted, Thanks a lot for this analysis. > In FLOAT_DIVU() it hangs at the following: > while (a.m >= b.m) > { > e++; > a.m >>= 1; > } > for the case where a and b are both zero (yes, division by zero). > This happens from mdf.c: True, that needs to be fixed even after I fix the rest. > leak_estimate =

Probably the level of your signal is too low and/or you're just not letting it time to adapt. Jean-Marc Le mercredi 19 juillet 2006 ? 19:00 -0400, ac2491@columbia.edu a ?crit : > On closer looks and debugging I always end up in > > speex_echo_cancel function with comment > /* Temporary adaption rate if filter is not adapted correctly */ > > > Does this give any clue

Hi Jim, I've just been made aware of these problems (look for the thread "speex echo cancellation limitations"). It's on my short-term TODO list. > If fftwrap.c, I ifdefed out the spx_fft_float and spx_ifft_float routines, > because there were not used and required smallft.c (which is not so small at > all) to be added to the build. Right, need to cleanup that

It appears that the chromatic adaptation feature of `grDevices::convertColor`is broken, and likely has been for many years.? While a little surprising, it is an obscure enough feature that there is some possibility this is actually broken, as opposed to user error on my part.? If it turns out to the latter, I apologize in advance for spamming this list. Consider: ??? rgb.in <-

An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20040715/b3253d77/attachment.htm -------------- next part -------------- ? Hi, I have some queries: I am using speex in Windows platform. 1. I am having some problem with the speex,for input 8KHz,8bits/sample mono stream i am getting output as 8KHz, 16bits/sample mono stream. I would like to know

Just tried your files and I'm not running into any infinite loops and the cancellation works fine. Unless the C6x has the same problem, I suspect a 16-bit problem. I'll check and see if I find something. About the r=0 problem, I can't find where it ends up in a denominator, so I suspect is not (directly) the problem. Jean-Marc Le lundi 08 mai 2006 ? 20:05 -0400, Jim Crichton a ?crit

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: preproc_patch_dth_10_26_05.patch Type: application/octet-stream Size: 8774 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20051026/c27a3ed6/preproc_patch_dth_10_26_05.obj

Hi, I'm still working on visualizing the echo canceller, but I discovered something that might be interresting. During testing, i did this: Generate a test signal (10+x sine waves per frame), where x increases by one for each iteration, and wraps around at 100. Set the speaker signal for the frame to the test signal. Add 0.5*test signal to the mic signal. When watching the power graph

Jean-Marc, I have traced the second infinite loop further. When st->adapted becomes true (mdf.c line 623), the first Yf[i] value is 4, the leak_estimate is 0xd4e, the resulting r is 3. The first value in st->Rf is 0, so e is 1, and r is set to e>>1, or 0. A little later there is a divide by r, and there is the hang. It seems that the 0 in Rf[0] is the problem, but I am not

> I built and ran the same test on the TI C64 simulator, and the echo was > canceled nicely (about 10:1 reduction in the peak amplitude during the > second of two brief speech bursts). So, my problem must again be related to > the 16-bit processing on the C5X DSPs. Good. At least we've narrowed it down a bit. > Also, the line where it is hanging is: >

? ? Hi Jean-Marc, When speech is played in speaker, we are feeding that speech to echo canceller for cancelling its echo from captured data and the echo canceller work very well. But when there is no speech, we are feeding samples of value zero to speaker and the same to echo canceller. But microphone is always capturing something. But when speech is played again after these zeros(silent

Hi Julian, > Some areas/ideas we are especially interested in: > Adaption of Clang to support OpenMP (http://clang-omp.github.io/), but haven't been able to contact one of the developers yet. This project is owned by my team, and we certainly welcome contributions! Have you tried to contact us via https://github.com/clang-omp/clang/issues ? Either way, it is really hard to find a

On Sat, Mar 12, 2016 at 06:31:13PM +0100, Reindl Harald wrote: > > i personally don't care what any soho-equipment manufacturer does or not, so > it's not abut "attitude" - it's simple logic - and maybe the switch to GPLv3 > is the reason for the whole subject "The sad state of samba 4 adaption" Utter bollocks, and I have the OEMs to prove it.

Although this SmartLink comes with a Linux program to monitor it, I'd rather use nut if possible. The biggest reason for preferring nut is that the supplied software forces one to set the On Battery time rather than allowing the battery to go critical and then sending a shutdown. Guessing how long the battery will last is problematical, especially as the battery ages. The other big reason

Hi, If I pass the same ref and the echo data to the echo cancellation API, I am expecting silence as output. I get back the original audio data. Is this correct? Thanks -Anurag Quoting ac2491@columbia.edu: > Hi Jean, > > I got the earlier problem fied with correct NN and tail values. > But > I dont see any echo being cancelled. To the echo cancel API I am > giving, audio

Dear Clang/LLVM community! We (a group of 3 highly motivated CS grad students) are taking a class about compilers and optimizations. This class offers the option of doing a implementation project (instead of reading/writing x papers) for its main part. Of course hacking is much more fun than ... ;) So my question is do you know of any open points, compiler passes, optimizations in the LLVM /