search for: fft_wrap

...function speex_echo_state_init in mdf.c I am getting error: "undefined reference to exp". I don't see a fixed point implementation of "exp". Can you point me to the correct files. I am using the following files from speex 1.2 beta1 => mdf.c, math_approx.c, misc.c, fft_wrap.c, kiss_fft.c, config.h, speex_types.h, speex_echo.h, arch.h . -Deepa -Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: Deepa Bhatt a ?crit : > Analog Devices sponsored a fixed point version for AEC which was > posted early this year, but it seems from the source code...

...T code, but I guess that it > is doing much more than the radix2 version in the TI library. The FFT code has more than just the radix two, so you can save there. It wasn't meant to be an optimized FFT, so if TI supplies you with one, it's probably a good idea to use it (that's what fft_wrap is for). Also, given that the memory use is almost directly proportional to the tail length, reducing that one to 40 ms will make a huge difference. Jean-Marc

...ing much more than the radix2 version in the TI library. > > > > The FFT code has more than just the radix two, so you can save there. It > > wasn't meant to be an optimized FFT, so if TI supplies you with one, > > it's probably a good idea to use it (that's what fft_wrap is for). Also, > > given that the memory use is almost directly proportional to the tail > > length, reducing that one to 40 ms will make a huge difference. > > Thanks for the advice. > > - Jim > > >

Analog Devices sponsored a fixed point version for AEC which was posted early this year, but it seems from the source code that the fft routines are still in floating point. Is the port still not complete or am I missing something? Has anyone out there ported speex AEC on RISC architecture? Please let me know. Thanks in advance, -Deepa -------------- next part -------------- An HTML

...he radix2 version in the TI library. > > > > > > The FFT code has more than just the radix two, so you can save there. It > > > wasn't meant to be an optimized FFT, so if TI supplies you with one, > > > it's probably a good idea to use it (that's what fft_wrap is for). Also, > > > given that the memory use is almost directly proportional to the tail > > > length, reducing that one to 40 ms will make a huge difference. > > > > Thanks for the advice. > > > > - Jim > > > > > > > > >

...t; it >> is doing much more than the radix2 version in the TI library. > > The FFT code has more than just the radix two, so you can save there. It > wasn't meant to be an optimized FFT, so if TI supplies you with one, > it's probably a good idea to use it (that's what fft_wrap is for). Also, > given that the memory use is almost directly proportional to the tail > length, reducing that one to 40 ms will make a huge difference. The overall allocated memory usage of the echo canceler is, in bytes: 4*frame_size *(27 + 5*ceiling(filter_length/frame_size)) + C Where C...

...t; it >> is doing much more than the radix2 version in the TI library. > > The FFT code has more than just the radix two, so you can save there. It > wasn't meant to be an optimized FFT, so if TI supplies you with one, > it's probably a good idea to use it (that's what fft_wrap is for). Also, > given that the memory use is almost directly proportional to the tail > length, reducing that one to 40 ms will make a huge difference. Thanks for the advice. - Jim

...ing much more than the radix2 version in the TI library. > > > > The FFT code has more than just the radix two, so you can save there. It > > wasn't meant to be an optimized FFT, so if TI supplies you with one, > > it's probably a good idea to use it (that's what fft_wrap is for). Also, > > given that the memory use is almost directly proportional to the tail > > length, reducing that one to 40 ms will make a huge difference. > > Thanks for the advice. > > - Jim > > >

...n in the TI library. > > > > > > The FFT code has more than just the radix two, so you can save there. > > > It > > > wasn't meant to be an optimized FFT, so if TI supplies you with one, > > > it's probably a good idea to use it (that's what fft_wrap is for). > > > Also, > > > given that the memory use is almost directly proportional to the tail > > > length, reducing that one to 40 ms will make a huge difference. > > > > Thanks for the advice. > > > > - Jim > > > > > > >...

...> > > > > > > The FFT code has more than just the radix two, so you can save there. > > > > It > > > > wasn't meant to be an optimized FFT, so if TI supplies you with one, > > > > it's probably a good idea to use it (that's what fft_wrap is for). > > > > Also, > > > > given that the memory use is almost directly proportional to the tail > > > > length, reducing that one to 40 ms will make a huge difference. > > > > > > Thanks for the advice. > > > > > > - Jim...

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 =