similar to: Fixed-point scaling of mdf impulse response

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

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

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

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

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

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

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

I have been working on a project importing Speex to a embedded platform for a while. When I tried to shut down the macro TWO_PATH in Speex AEC to save space, an error occurred. Dbf is undefined. The 1.2rc1 code is like this Dbf = 0; See = 0; #ifdef TWO_PATH /* Difference in response, this is used to estimate the variance of our residual power estimate */ for (chan = 0; chan < C;

Hi, Here are the next two patches for the data export. speex_get_psd should be applied after speex_get_agc_gain (sent in previous mail). It allows applications to get the power spectrum for the signal and the noise estimate. speex_get_prob should be applied last. It allows fetching the speech probability of the current frame (the value that the _PROB_START and _PROB_CONTINUE parameters are

Hi, Ref the disucussion on IRC yesterday; here's a patch which makes a bit more data from the analysis of the preprocessor and the echo canceller available. For the preprocessor: - Size of power spectrum. - Power spectrum and noise estimate of the previous frame. These are given as squared values, so sqrt() to get values in the 0->32767 range. - Current amplification level

Jean-Marc, I recently started looking at running the echo canceller on a TI C55 DSP along with the 8kbps narrowband Speex encoder/decoder. This is one of those "braindead compilers" that you refer to from time to time, and cannot handle the float struct assignments in the return statements in pseudofloat.h. Most of these were eliminated in build 11311 (patch by Brian Retford), but

Jean-Marc, I have traced the second infinite loop further. When st->adapted becomes true (mdf.c line 623), the first Yf[i] value is 4, the leak_estimate is 0xd4e, the resulting r is 3. The first value in st->Rf is 0, so e is 1, and r is set to e>>1, or 0. A little later there is a divide by r, and there is the hang. It seems that the 0 in Rf[0] is the problem, but I am not

From: Thorvald Natvig <slicer at users.sourceforge.net> Some optimizing compilers miscompile the current SSE optimizations when full optimizations are enabled. By using output value pointer instead of a return value, we can bypass this misbehaviour. --- libspeex/resample.c | 8 ++++---- libspeex/resample_sse.h | 24 ++++++++---------------- 2 files changed, 12 insertions(+), 20

From: Jyri Sarha <jsarha at ti.com> Semantics of inner_product_single have also been changed to contain the final right shift and saturation so it can also be implemented in the optimal way for the used platform. This change affects fixed point calculations only. I also added a new fixed point macro SATURATE32PSHR(x, shift, a). It does pretty much the same thing as SATURATE32(PSHR32(x,

Hi, I''am trying to use DRBD with XEN 3.0, the xen kernel is an 2.6.12.6 and i am using DRBD 0.7.14. The primary node is an opensuse 10 linux (not virtualized). The 2 volumes are LVM logical volumes with internal metadatas, there size is 54G. The secondary node is an opensuse 10 also but running over xen domain-0. When i setup drbd, synchronisation starts, but the whole system just

O.k., some more info: I just tested bandwidth widening to fix this. But I need to go to gamma values below 0.9 to become stable -- clearly too much widening, I think. I looked inside the Levinson-Durbin algorithm next. The lines #ifdef FIXED_POINT r = DIV32_16(rr+PSHR32(error,1),ADD16(error,8)); #else r = rr/(error+.003*ac[0]); #endif look interesting. While for floating point,

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

Hi Jean-Marc, I did what you proposed. I changed the levinson durbin algorithm to: { int i, j; spx_word16_t r; spx_word16_t error = ac[0]; for (i = 0; i < p; i++) lpc[i] = 0; if (ac[0] == 0) { //for (i = 0; i < p; i++) // lpc[i] = 0; return 0; } for (i = 0; i < p; i++) { /* Sum up this iteration's reflection coefficient