search for: pseudofloat

...build wins udeb (to build for emulator) but building failed, the error message is : nmake -nologo -x - -s -f "\Install\Symbian\8.0a\S60_2nd_FP2\EPOC32\BUILD\HOME\MYOWN\NOKIA\SPEEX\SPEEX-1.1.12\SYMBIAN\SPEEX\WINS\SPEEX.WINS" LIBRARY Mdf.c c:\HOME\MyOwn\Nokia\Speex\speex-1.1.12\libspeex\pseudofloat.h(63) : error C2059: syntax error : '{' c:\HOME\MyOwn\Nokia\Speex\speex-1.1.12\libspeex\pseudofloat.h(109) : error C2061: syntax error : identifier 'FLOAT_SUB' and many similiar erros in mdf.c \HOME\MyOwn\Nokia\Speex\speex-1.1.12\libspeex\mdf.c(548) : error C2440: 'function'...

...ts and > modified the tests for == 0 to <= 0 ... > > Clearly, some sort of automated testing scheme could help here... One thing I used to do (should do it more often) is test with FIXED_DEBUG (--enable-fixed-point-debug) which puts assertions in all fixed-point operators (except the pseudofloat stuff, which is rather new). Helps a lot tracking problems down. Jean-Marc

...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 > there were four left that I had to break apart. I started with build > 11343. > > I got several compiler warnings for "shift out of range" in mdf.c, which I > fixed by adding EXTEN...

...me to trace this, but it looks like a similar problem, > > >> where the result of MULT16_32_Q15(M_1,r) is negative, and > > >> FLOAT_DIV32_FLOAT > > >> bombs. Maybe the best thing to do next is to instrument the routines > > >> in > > >> pseudofloat.h which have loops, but I will not get to that for a day or > > >> two. > > > > > > Yeah, r is never supposed to be negative and the float routines assume > > > that. > > > > No, it was a divide by zero, as explained in my second post. I will try...

Hi everyone, For all those of you who always wanted to contribute to Speex, but didn't know what to do, I've just updated the list of things that could be done on: http://wiki.xiph.org/index.php/Speex The tasks range from maintaining a FAQ to writing a better perceptual enhancer. Some of the more complex things listed would even make a good university project! If you're interested in

Jean-Marc, Well I finally tracked down the problem. Then I checked my mail and found that you had fixed it several hours earlier. :( 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 different way. Also in the pseudofloat.h is the change to EXTRACT16 which I mentioned earlier in...

..., 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 there were four left that I had to break apart. I started with build 11343. 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 b...

> 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 > different way. Funny thing is I applied exactly the same patch to nb_celp.c a few h...

.... > > >> I have not had time to trace this, but it looks like a similar problem, > >> where the result of MULT16_32_Q15(M_1,r) is negative, and > >> FLOAT_DIV32_FLOAT > >> bombs. Maybe the best thing to do next is to instrument the routines in > >> pseudofloat.h which have loops, but I will not get to that for a day or > >> two. > > > > Yeah, r is never supposed to be negative and the float routines assume > > that. > > No, it was a divide by zero, as explained in my second post. I will try a > build on the C6x DSP...

...h a few emulated floating point operations for gain > computation > - extract gain mantissa and exponent > - multiply fixed-point buffer by mantissa > - offset spectrum exponent before IFFT reconstruction > > What do you think ? It would be even better if you could do it with my pseudofloat macros. It defines a float approximation with 16-bit mantissa and 16-bit exponent. It takes cuts corners all over the place (makes all kind of assumptions), but it's faster than emulating IEEE float and it would be cleaner since the code is already there. Cheers, Jean-Marc

...sufficient to remove all the overflows at this place? > I have not had time to trace this, but it looks like a similar problem, > where the result of MULT16_32_Q15(M_1,r) is negative, and FLOAT_DIV32_FLOAT > bombs. Maybe the best thing to do next is to instrument the routines in > pseudofloat.h which have loops, but I will not get to that for a day or two. Yeah, r is never supposed to be negative and the float routines assume that. > 1. speex_echo_state_init takes about 20M instructions, which is a little > frightening, That's the fft initialization that calls a lot of f...

...ed to avoid the sign extension. >> I have not had time to trace this, but it looks like a similar problem, >> where the result of MULT16_32_Q15(M_1,r) is negative, and >> FLOAT_DIV32_FLOAT >> bombs. Maybe the best thing to do next is to instrument the routines in >> pseudofloat.h which have loops, but I will not get to that for a day or >> two. > > Yeah, r is never supposed to be negative and the float routines assume > that. No, it was a divide by zero, as explained in my second post. I will try a build on the C6x DSP to see if this is a 16 vs. 32-bit...

...gt;> I have not had time to trace this, but it looks like a similar problem, > >> where the result of MULT16_32_Q15(M_1,r) is negative, and > >> FLOAT_DIV32_FLOAT > >> bombs. Maybe the best thing to do next is to instrument the routines > >> in > >> pseudofloat.h which have loops, but I will not get to that for a day or > >> two. > > > > Yeah, r is never supposed to be negative and the float routines assume > > that. > > No, it was a divide by zero, as explained in my second post. I will try a > build on the C6x DSP to...

...hat all the shifting is about) This same code fragment is in normalize16() and compute_rms() and a couple of other spots. I think it should be encapsulated into a norm_shift() function that can be overridden for specific processors. Similarly, the AEC code uses FLOAT_ADD, _SUB, _MULT routines in pseudofloat.h could be improved by shifting negative mantissa's >= -16384. if (r.m>0) { if (r.m<16384) { r.m<<=1; r.e-=1; } }else { if (r.m>=-16384) { r.m<<=1; r.e-=1; } } return(r); Here...

> I am writing to gain a better understanding of the limitations of speex echo > cancellation, esp. with respect to the fixed point implementation. > If these limitations have been documented elsewhere already, please let me > know! Nothing officially documented, sorry. > I observe experimentally that when one or both of the echo or ref data for > speex_echo_cancel() have

Hi Jean-Marc, As I told you, bank is a reserved keyword in Analog Devices compiler for Blackfin architecture. So we need to change the variables named bank to something else. Here's a patch that changes bank to bnk in the 3 concerned files. (Hope the format is OK) About my previous problems with the Blackfin: -> strange block repetition that could be cancelled by the AEC I was busy

You might not be doing anything wrong. Speex is stateful and can get into a bad state sometimes. It's happened to me too, but not recently. And I've seen such bugs reported on this list and fixed. I suggest several approaches to solving the problem: 1) Try compiling Speex without compiler optimizations and see if the problem still occurs. Most likely it will, but this is an