similar to: question about spx_fft

Thanks for the explaination. Please see my questions and comment in lines. On 4/16/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > (keeping this on the list) > > William Zhang wrote: > > I read the mdf.c an my understanding is that N is actually window size for > > the FFT. The actual length L = N/2 which is the frame length. The > > second part

Hi, I'm one of the people working on the Rockbox project (http://www.rockbox.org) which is an open source alternative firmware for a range Digital Audio Players. Recently we integrated support for the Speex codec using libspeex and seems to work well. If you could add Rockbox to your list of software that supports Speex, that'd be great. So that's the introduction done. Now for

I am in the process of dropping the TI DSP lib fft routines into the AEC. Currently, FFTWrap.c uses the USE_SMALLFT and USE_KISS_FFT to select between two packages of FFT routines. ] #ifdef USE_SMALLFT ... #elif defined(USE_KISS_FFT) ... #else #error No other FFT implemented #endif My guess is that every DSP and many other processors will have their own specific FFT and iFFT. What method

(keeping this on the list) William Zhang wrote: > I read the mdf.c an my understanding is that N is actually window size for > the FFT. The actual length L = N/2 which is the frame length. The > second part of the buffer is padded with the new frame data. So this is > like the overlap-save method for improving the acuracy in calculating > the fft of > long sequence of data?

hi, this patch should fix the symbian build. /alfred -------------- next part -------------- A non-text attachment was scrubbed... Name: speex-symbian2.patch Type: text/x-patch Size: 2669 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20061115/5ac4915e/speex-symbian2.bin

hi Jean-Marc, I just updated from svn and it looks like there are some errors in the speex.mmp file. the filters.c is duplicated, and the fft/kiss.c files are still missing.. /alfred Jean-Marc Valin wrote: > Applied in svn. Thanks. > > Jean-Marc > > Alfred E. Heggestad a ?crit : >> hi, >> >> this patch should fix the symbian build. >> >> >>

> 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 Dan, Thanks for the patch, I'll apply it to svn. One question, why do you need this: +void kiss_fftri2(kiss_fftr_cfg cfg,const kiss_fft_scalar *freqdata,kiss_fft_scalar *timedata); + Cheers, Jean-Marc Dan Everton a ?crit : > Hi, > > I'm one of the people working on the Rockbox project > (http://www.rockbox.org) which is an open source alternative firmware > for a

> Build 11387 produces the same result as my modified build 11343. Because of > compiler limitations in the TI tools, I did have to make modifications to > pseudofloat.h (separating return of float values) and nb_celp.c (adding > braces around a variable declaration in the middle of code). I have > attached a patch. You might prefer to do the nb_celp.c change in a >

? hi all, i am using the Acoustic Echo Cancellation from "Speex 1.1.12 version" in my VOIP application. Is it that the frame length to be chosen should always be 20ms or can i have flexibility in chosing the frame lenght? on what parameters does the frame length choise depends? thank you all, Shri. -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

Thanks Jean-Marc. Is there a Speex trunk for the C64xx I can use? Or do I have to figure what options to turn on (in configure) when building the library? Thanks. Regards, Andy Ngo ----- Original Message ---- From: Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> To: ndno72-speex@yahoo.com Cc: jtrantow@ieee.org; speex-dev@xiph.org Sent: Tuesday, December 5, 2006 2:52:02 PM Subject:

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 =

Hello to everyone! During building speex library for Symbian OS I encountered some problems. All thess problems can be solved by modifying the speex sources. I don't have access to SVN repository of speex, so I will just describe the changes to be done: 1) mmp file in symbian derictory misses windows.c sources. You need to add this string into speex.mmp: SOURCES windows.c 2) Symbian OS

Hi Jerry, I'd say the best would be to simply replace the #ifdef USE_SMALLFT by #ifdef USE_TI_FFT #include "ti_fft_wrapper.h" #elif defined(USE_SMALLFT) and have everything in the include file. There's no real point in overriding individual functions since they all go together. Also, make sure you wrap the FFT in the same way as I did with the fixed-point kissfft. For example,

Dear all, Sorry for this simple and maybe stupid question, I'm working in the implementation of opus for ARMv7e microcontroller using a library CMSIS/DSP used to calculate the CFFT and MDCT based on the DCT-IV. my question is: In the implementation of Celt you have used a fixed length CFFT equal to 1920, I want to know if there is some issues which can appear if a change that configuration

Changes from RFC PATCH v1: - passing arch parameter explicitly - reduced stack usage by ~3.5K by using scaled NE10 fft version - moved all optimization array functions to arm_celt_map.c - Other cleanups pointed out by Timothy Phil, As you mentioned earlier, could you please address all compile and linker errors/warnings coming out of Ne10 library? You can find my working Ne10 repo at [1] You

Changes from RFC PATCH v2 - fixed compile issue when just compiling for --enable-intrinsics for ARMv7 without NE10 - Notes for NE10: - All compile/link warnings are now in upstream NE10 - Only patch pending upstream in NE10 is the one that needs to add -funsafe-math-optimizations for ARMv7 targets. - Phil Wang @ ARM is working on getting this fixed. - Note that even without

Changes from RFC PATCH v3 - Just rebased on tip - For all else, please see notes from RFC PATCH v3 at http://lists.xiph.org/pipermail/opus/2015-March/002902.html - latest wip opus tree/branch https://git.linaro.org/people/viswanath.puttagunta/Ne10.git branch: rfcv4_final_fft_ne10 Viswanath Puttagunta (1): armv7(float): Optimize encode usecase using NE10 library Makefile.am