search for: adapt_r

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: libspeex/mdf.c =================================================================== --- libspeex/mdf.c (revision 10357) +++ libspeex/mdf.c (working copy) @@ -314,11 +314,1...

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

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 million). Not quite sure where to begin with debugging, and the problem is "solved...

...etup the echo is created by an analog modem connected to an analog line. The signal I get from the modem contains the voices of both the caller and the callee in almost the same volume. The biggest problems I have encountered so far: having clear tones while the filter is adapting (I play with the adapt_rate during the conversation). These tones will have a major bad impact on the filter. So I've hacked the telephone program that it will put the adapt_rate at 0 when "silence" is detected at the microphone. My latest problem I try to concur is when I adapt_rate = 0 (the filter has alre...

Hi, I am currently working on a thin-client "low-cpu" usage telephone application. The current setup is that you can make phonecalls using an alsa supported usb headset and a smartlink based usb modem (a sweex usb modem, which -in large quantities- goes for 17.95 euro's) for analog lines. Unfortunately, it is really made as a modem and not for audio purposes, so, there is a pretty

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 =

.... > > > > Yes, there may be a bit of memory reduction possible here. Of course, > > decreasing the tail length is also a rather easy way. > > > >> When I run the build, it goes into an infinite loop in FLOAT_DIV32 (mdf.c > >> line 660), which occurs because adapt_rate is < 0, which happens when > >> FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is causing > >> the result to go negative. I worked around this by changing > > > > I think that was mentioned in the previous thread... > > > >>...

...>20kbytes of dynamic data > memory for block size=128, tail length = 1024), and I will probably not be > able to fit it in the production build without some trimming. > > When I run the build, it goes into an infinite loop in FLOAT_DIV32 (mdf.c > line 660), which occurs because adapt_rate is < 0, which happens when > FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is causing > the result to go negative. I worked around this by changing > > return (a.m+(1<<(-a.e-1)))>>-a.e; > to > return (((spx_uint16_t) a.m)+(1<<(...

>> 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 ;) > > Where have you been the past 6 years? It is valid C99 (even if it's confusing > for non-C++-minded people). "...

...a bit of memory reduction possible here. Of course, > > > decreasing the tail length is also a rather easy way. > > > > > >> When I run the build, it goes into an infinite loop in FLOAT_DIV32 > > >> (mdf.c > > >> line 660), which occurs because adapt_rate is < 0, which happens when > > >> FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is > > >> causing > > >> the result to go negative. I worked around this by changing > > > > > > I think that was mentioned in the previous...

...to fit it in the production build without some trimming. Yes, there may be a bit of memory reduction possible here. Of course, decreasing the tail length is also a rather easy way. > When I run the build, it goes into an infinite loop in FLOAT_DIV32 (mdf.c > line 660), which occurs because adapt_rate is < 0, which happens when > FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is causing > the result to go negative. I worked around this by changing I think that was mentioned in the previous thread... > return (a.m+(1<<(-a.e-1)))>>-a.e; > to...

...more than I had hoped (>20kbytes of dynamic data memory for block size=128, tail length = 1024), and I will probably not be able to fit it in the production build without some trimming. When I run the build, it goes into an infinite loop in FLOAT_DIV32 (mdf.c line 660), which occurs because adapt_rate is < 0, which happens when FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is causing the result to go negative. I worked around this by changing return (a.m+(1<<(-a.e-1)))>>-a.e; to return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; in...

...on build without some trimming. > > Yes, there may be a bit of memory reduction possible here. Of course, > decreasing the tail length is also a rather easy way. > >> When I run the build, it goes into an infinite loop in FLOAT_DIV32 (mdf.c >> line 660), which occurs because adapt_rate is < 0, which happens when >> FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is causing >> the result to go negative. I worked around this by changing > > I think that was mentioned in the previous thread... > >> return (a.m+(1<<(-a.e-1)...

...; > Yes, there may be a bit of memory reduction possible here. Of course, > > decreasing the tail length is also a rather easy way. > > > >> When I run the build, it goes into an infinite loop in FLOAT_DIV32 > >> (mdf.c > >> line 660), which occurs because adapt_rate is < 0, which happens when > >> FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is > >> causing > >> the result to go negative. I worked around this by changing > > > > I think that was mentioned in the previous thread... > > >...

...a bit of memory reduction possible here. Of course, > > > decreasing the tail length is also a rather easy way. > > > > > >> When I run the build, it goes into an infinite loop in FLOAT_DIV32 > > >> (mdf.c > > >> line 660), which occurs because adapt_rate is < 0, which happens when > > >> FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is > > >> causing > > >> the result to go negative. I worked around this by changing > > > > > > I think that was mentioned in the previous t...

...n possible here. Of course, > > > > decreasing the tail length is also a rather easy way. > > > > > > > >> When I run the build, it goes into an infinite loop in FLOAT_DIV32 > > > >> (mdf.c > > > >> line 660), which occurs because adapt_rate is < 0, which happens when > > > >> FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is > > > >> causing > > > >> the result to go negative. I worked around this by changing > > > > > > > > I think that was me...