search for: kissfft

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

...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. There are two FFTs in Speex, one of which (kissfft) works in fixed-point (and is enabled by default). The AEC works fine at least on Blackfin. Jean-Marc > Thanks in advance, > > -Deepa > > > > ------------------------------------------------------------------------ > > > ________________________________________...

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

...xed point fft, preferrably that didn't use assembly. I tried to find an ANSI C fft routine that would do fixed point. I couldn't, so I wrote KISS FFT: a simple, portable radix2 FFT library that can be compiled to use either fixed or floating point math. See http://sourceforge.net/projects/kissfft Now the problem of IIR filters: IIR filters and fixed point math do not mix well. Truncation errors and limited dynamic range problems are amplified by the feedback nature of the IIR. There are a bunch of IIR filters used in speex. It seems to me that using the rounded impulse responses of those...

...LFT 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, the forward fft is normalised, while the backward one isn't. Also, in some cases, I do some renormalisation before the fft to increase accuracy. Please send me the patch when you have something working. I'm sure other people would be interested. Jean-Marc Jerry Trantow a ?...

...t sizes of 480, 240, 120, and 60, I guess that internally the input data is padded with zeros in order to compute efficiently the mdct using the Cooley and Tukey algorithm. If I'm correct. Means that technically, I could compute the fft using the padding strategy and adjust the output such as kissfft done, someone could confirm if that is possible. thanks cheers On Wed, Apr 12, 2017 at 2:27 PM, Diego Alejandro Parra Guzman < daparrag at correo.udistrital.edu.co> wrote: > Dear all, > > Sorry for this simple and maybe stupid question, I'm working in the > implementation o...

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

Jean-Marc Valin wrote: > There is definitely some use for a Neon fixed-point FFT. How much > exactly I'm not sure. Fixed-point is a bit more than just a fall-back Well, we use fixed-point mode by default in Firefox for both Firefox OS and Fennec (Firefox on Android). The reason is that, although there is some NEON-class hardware where float does finally appear to be a little bit

<with Prof. Farnsworth voice> "Good News, everyone". I've just kicked off project "Sphinx". Which is supposed to sound like "Speex" merged with "INT". ;) Meaning I am working on an integer encoder and decoder. It looks like I will be pulling in a new "integer plumbing" into the foundation of the codec, comparing the results with the old