similar to: Shift count warning messages

yes, our DSP is 16 bit based, and if those bits of code aren't using 32 bit variables then yes that is what the warnings would be. Does this mean that the preprocessor and echo canceller won't work as well because of this? -Mike >>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 01/18/08 8:42 PM >>> I think these warnings are due to your DSP being 16-bit and

Jim Crichton a ?crit : > I played briefly with the echo canceller on the C5509A back in May > 2006. I got the same compiler warnings, and sent a message to the > list which included this: > > "I got several compiler warnings for "shift out of range" in mdf.c, > which I fixed by adding EXTEND32 to all of the SHL32s with 16 bit > operands (st->frame_size in 6

Thanks Jim for looking into that, I was really starting to wonder what was going on. Let me know if you find a way to tell the compiler to 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

Hi Jim, Thanks a lot for investigating. It definitely makes sense now. I'll fix the problem now. Is there any other place where you see that same (or similar) problem? Jean-Marc Jim Crichton a ?crit : > Jean-Marc, > > I dug into this further, and found that the warning occurred when PSHR32 > had a shift greater than 15. > > in fixed_generic.h, PSHR32 is defined as: >

Mike, I played briefly with the echo canceller on the C5509A back in May 2006. I got the same compiler warnings, and sent a message to the list which included this: "I got several compiler warnings for "shift out of range" in mdf.c, which I fixed by adding EXTEND32 to all of the SHL32s with 16 bit operands (st->frame_size in 6 places, st->wtmp2 in 1 place)." I sent

Jean-Marc, I dug into this further, and found that the warning occurred when PSHR32 had a shift greater than 15. in fixed_generic.h, PSHR32 is defined as: #define PSHR32(a,shift) (SHR32((a)+((1<<((shift))>>1)),shift)) For 16-bit compilers the "1" needs a cast: #define PSHR32(a,shift) (SHR32((a)+((EXTEND32(1)<<((shift))>>1)),shift)) This change fixed the

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

Hi, I made a small error in the impulse reponse function; when doing the inverse fft in fixed point, it will overflow unless it's properly scaled. This patch uses the same scaling as that used when updating the filters, and the outputs now have the same shape and the same scale in fixed and floating point. Best regards, Thorvald -------------- next part -------------- diff -ubBwr

Hello, This patch introduces ARM NEON Intrinsics to optimize kf_bfly4 routine in celt part of libopus. Using NEON optimized kf_bfly4(_neon) routine helped improve performance of opus_fft_impl function by about 21.4%. The end use case was decoding a music opus ogg file. The end use case saw performance improvement of about 4.47%. This patch has 2 components i. Actual neon code to improve

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

Hi, Here's the second attempt of a patch to get the impulse response from the echo canceller :) -------------- next part -------------- diff -ubBwr clean/include/speex/speex_echo.h get_impulse/include/speex/speex_echo.h --- clean/include/speex/speex_echo.h 2007-10-09 13:08:15.000000000 +0200 +++ get_impulse/include/speex/speex_echo.h 2008-02-12 23:58:11.000000000 +0100 @@ -51,6 +51,14 @@

> 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 >

> 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, I am using speex1.2beta2 on a TI 54x on narrow band I have been trying to get speex to work for a while now, and it's been a real teeter-totter ride. For a long time I noticed that I will get a project to work and then without changing any code and programming it to an eprom/flash the project will not work. It turns out it was a value called innov_save. I found this bugger by zero

Optimize kf_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

> misc.c provides the ability to override some functions, including the > allocation and printing. fftwrap.c uses speex_alloc, then calls > kiss_fftr_alloc, which calls kiss_fft_alloc, which calls KISS_FFT_MALLOC, > which is defined as malloc in kiss_fft.h. It would make it more consistent > to define KISS_FFT_MALLOC as speex_alloc. That is the only change that I > would

Hi, I am using 1.2beta2 on a C5416 doing narrowband in the decode function I am having a problem with the execution of my program vectoring off to random interrupts that are not used. I have tracked down the error to the highpass function called in nb_decode -very close to the end of the function-context: it is called here: ln 1719 for me if (st->highpass_enabled) highpass(out,

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 =

Hi all, This is Linfeng Zhang from Google. I'll work on ARM NEON optimization in the next few months. I'm submitting 2 patches in the following couple of emails, which have the new created celt_fir_neon(). I revised celt_fir_c() to not pass in argument "mem" in Patch 1. If there are concerns to this change, please let me know. Many thanks to your comments. Linfeng Zhang

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