search for: kiss_fft

...on a NiosII processor (for those who don't know the NiosII, this is a soft core processor for FPGAs from Altera) which worked pretty well. In order to take away some of the processing load from the processor, I have now developed a FFT co-processor which is basically compatible to the original kiss_fft algorithm. Before I start now to integrate my co-processor into the celt code, I would like to check whether the changes, that were made to the original kiss_fft code, change the actual behaviour of the kiss_fft function or whether they were only made for speed improvement or cosmetic reasons. In o...

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

...+++++ celt/arm/celt_ne10_fft.c | 26 +++++++++++ celt/arm/celt_ne10_mdct.c | 102 ++++++++++++++++++++++++++++++++++++++++++++ celt/arm/fft_arm.h | 8 ++++ celt/arm/mdct_arm.h | 7 +++ celt/celt_decoder.c | 18 ++++---- celt/celt_encoder.c | 3 +- celt/kiss_fft.c | 4 +- celt/kiss_fft.h | 13 +++++- celt/mdct.c | 5 ++- celt/mdct.h | 22 ++++++++-- celt/tests/test_unit_dft.c | 2 +- celt/tests/test_unit_mdct.c | 2 +- 13 files changed, 214 insertions(+), 20 deletions(-) -- 1.9.1

Hi, I'm using 1.2beta3 on a 5416 DSP I have been getting warning messages that say: "kiss_fft.c", line 142: warning: shift count is too large I've noticed this on the echo canceller and the preprocessor. all pretty much related to these two lines of code: kiss_fft C_MUL4(scratch[0],Fout[m] , *tw1 ); mdf.c st->wtmp2[i] = EXTRACT16(PSHR32(st->W[j*N+i],NORMALIZE_SCALEDO...

...+++++ celt/arm/celt_ne10_fft.c | 26 +++++++++++ celt/arm/celt_ne10_mdct.c | 102 ++++++++++++++++++++++++++++++++++++++++++++ celt/arm/fft_arm.h | 8 ++++ celt/arm/mdct_arm.h | 7 +++ celt/celt_decoder.c | 18 ++++---- celt/celt_encoder.c | 3 +- celt/kiss_fft.c | 4 +- celt/kiss_fft.h | 13 +++++- celt/mdct.c | 5 ++- celt/mdct.h | 22 ++++++++-- celt/tests/test_unit_dft.c | 2 +- celt/tests/test_unit_mdct.c | 2 +- 13 files changed, 214 insertions(+), 20 deletions(-) diff --git a/celt/...

...+++++ celt/arm/celt_ne10_fft.c | 26 +++++++++++ celt/arm/celt_ne10_mdct.c | 102 ++++++++++++++++++++++++++++++++++++++++++++ celt/arm/fft_arm.h | 8 ++++ celt/arm/mdct_arm.h | 7 +++ celt/celt_decoder.c | 18 ++++---- celt/celt_encoder.c | 3 +- celt/kiss_fft.c | 4 +- celt/kiss_fft.h | 13 +++++- celt/mdct.c | 5 ++- celt/mdct.h | 22 ++++++++-- celt/tests/test_unit_dft.c | 2 +- celt/tests/test_unit_mdct.c | 2 +- 13 files changed, 214 insertions(+), 20 deletions(-) diff --git a/celt/...

..._bfly4 function using ARM NEON intrinsics for SoCs that have NEON VFP unit As initial step, only targetting ARMv7-VFP based SoCs. To enable this optimization, use --enable-armv7-neon-float when running configure command. This is disabled by default. --- Makefile.am | 16 ++++ celt/_kiss_fft_guts.h | 13 +++ celt/arm/kiss_fft_neon.c | 211 ++++++++++++++++++++++++++++++++++++++++++++++ celt/arm/kiss_fft_neon.h | 37 ++++++++ celt/kiss_fft.c | 2 +- celt_headers.mk | 1 + celt_sources.mk | 3 + configure.ac | 14 +++ 8 files chan...

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 range Dig...

...formance measurements is available at [1] Please let me know your thoughts. [1]: https://docs.google.com/document/d/1l_VWknKMdR_6nn1zIjaawxP2u7p4F3OAt7jBeuAyqe0/edit?usp=sharing Viswanath Puttagunta (1): arm: kf_bfly4: Introduce ARM neon intrinsics Makefile.am | 16 ++++ celt/_kiss_fft_guts.h | 13 +++ celt/arm/kiss_fft_neon.c | 211 ++++++++++++++++++++++++++++++++++++++++++++++ celt/arm/kiss_fft_neon.h | 37 ++++++++ celt/kiss_fft.c | 2 +- celt_headers.mk | 1 + celt_sources.mk | 3 + configure.ac | 14 +++ 8 files chan...

...hese warnings are due to your DSP being 16-bit and that bit of code not being 16-bit safe (unlike the encoder and decoder). Can you confirm? Jean-Marc Michael Jacobson a ?crit : > Hi, I'm using 1.2beta3 on a 5416 DSP > > I have been getting warning messages that say: > "kiss_fft.c", line 142: warning: shift count is too large > > > I've noticed this on the echo canceller and the preprocessor. all > pretty much related to these two lines of code: > > kiss_fft > C_MUL4(scratch[0],Fout[m] , *tw1 ); > > mdf.c > st->wtmp2[i] =...

...P being 16-bit and that bit > of code not being 16-bit safe (unlike the encoder and decoder). Can > you confirm? > > Jean-Marc > > Michael Jacobson a ?crit : >> Hi, I'm using 1.2beta3 on a 5416 DSP >> >> I have been getting warning messages that say: "kiss_fft.c", line >> 142: warning: shift count is too large >> >> >> I've noticed this on the echo canceller and the preprocessor. all >> pretty much related to these two lines of code: >> >> kiss_fft C_MUL4(scratch[0],Fout[m] , *tw1 ); >> >&...

...stop complaining. Jean-Marc Jim Crichton a ?crit : > I looked back at my old C55 EC build, and I had the same warning in > mdf.c which Mike found. The assembly code did have a valid shift, and > this build did cancel echo. > > When I built with the SVN head, I saw the errors in kiss_fft.c also. > The assembly there also has valid shifts. > > So, I suspect that these warnings do not indicate a real problem. It > might be interesting to break down the offending lines into a sequence > of simpler instructions, to see if the compiler can be placated in that > way....

...t_arm.h | 53 +++++ celt/celt_encoder.c | 13 +- celt/dump_modes/Makefile | 23 +- celt/dump_modes/dump_modes.c | 21 ++ celt/dump_modes/dump_modes_arch.h | 41 ++++ celt/dump_modes/dump_modes_arm_ne10.c | 125 ++++++++++ celt/kiss_fft.c | 27 ++- celt/kiss_fft.h | 54 ++++- celt/mdct.c | 15 +- celt/mdct.h | 39 +++- celt/modes.c | 8 +- celt/static_modes_float.h | 25 ++ celt/static_m...

...m/mdct_arm.h | 53 +++++ celt/celt_encoder.c | 13 +- celt/dump_modes/Makefile | 23 +- celt/dump_modes/dump_modes.c | 21 ++ celt/dump_modes/dump_modes_arch.h | 41 ++++ celt/dump_modes/dump_modes_arm_ne10.c | 125 +++++++++++ celt/kiss_fft.c | 27 ++- celt/kiss_fft.h | 54 ++++- celt/mdct.c | 15 +- celt/mdct.h | 39 +++- celt/modes.c | 8 +- celt/static_modes_float.h | 25 +++ celt/static_modes_...

..., spx_word16_t *out) When I say standard, I mean the input "in" is 128 point short data for example and the output "out" is 128 short complex value which is stored in 256 short array with real and image part. Looks like the function did some manipulation on the output from the kiss_fft. I am still reading the codes and am not completely understand the code yet. I am trying to replace the fft module with some hardware logic. I would greatly appreciate it if you could clarify my doubts. Thank a lot! Regards, William

...39;ll need to have a closer look on that one. > Outside of what is in the patch, I ifdefed out the unused spx_fft_float and > spx_ifft_float in fftwrap.c (I described this earlier, it prevents the need > to include smallft.c) and commented out the memory.h and malloc.h includes > in kiss_fft.h (the TI compiler does not have these files). True, forgot about that one. > When the dust > settles, I will send a patch with additions to the TI directory for the echo > canceler example, including instructions on these last changes. Also, I > would like to modify the memory...

...m/mdct_arm.h | 53 +++++ celt/celt_encoder.c | 13 +- celt/dump_modes/Makefile | 23 +- celt/dump_modes/dump_modes.c | 21 ++ celt/dump_modes/dump_modes_arch.h | 41 ++++ celt/dump_modes/dump_modes_arm_ne10.c | 125 +++++++++++ celt/kiss_fft.c | 27 ++- celt/kiss_fft.h | 54 ++++- celt/mdct.c | 15 +- celt/mdct.h | 39 +++- celt/modes.c | 8 +- celt/static_modes_float.h | 25 +++ celt/static_modes_...

...on effects). > > > My hardware logic can perform N real point FFT real fast and it produce > > N complex fft results > > If that's the case, then you can still benefit by converting the N-point > real FFT into an N/2 point complex FFT and an update pass. This is what the kiss_fftr function does, right? > > RIRIRI...RI. How does it map to your N/2 complex > > output especially > > the first R and last R in your sequecne? > > The packing is actually R(0), R(1), I(1), R(2), I(2), ... R(N/2) > Because the input is real, it means that I(0) and R(N/2)...

...t_arm.h | 53 +++++ celt/celt_encoder.c | 13 +- celt/dump_modes/Makefile | 23 +- celt/dump_modes/dump_modes.c | 21 ++ celt/dump_modes/dump_modes_arch.h | 41 ++++ celt/dump_modes/dump_modes_arm_ne10.c | 125 ++++++++++ celt/kiss_fft.c | 27 ++- celt/kiss_fft.h | 54 ++++- celt/mdct.c | 15 +- celt/mdct.h | 39 +++- celt/modes.c | 8 +- celt/static_modes_float.h | 25 ++ celt/static_m...

...m/mdct_arm.h | 53 +++++ celt/celt_encoder.c | 13 +- celt/dump_modes/Makefile | 23 +- celt/dump_modes/dump_modes.c | 21 ++ celt/dump_modes/dump_modes_arch.h | 41 ++++ celt/dump_modes/dump_modes_arm_ne10.c | 125 +++++++++++ celt/kiss_fft.c | 27 ++- celt/kiss_fft.h | 54 ++++- celt/mdct.c | 15 +- celt/mdct.h | 39 +++- celt/modes.c | 8 +- celt/static_modes_float.h | 25 +++ celt/static_modes_...