search for: fixed_debug

...32)( \ + (( 0.5 + (double)(x) * ((opus_val32)(1)<<(bits)) ) >= (double)(INT32_MAX) ) ? \ + (opus_val32)(INT32_MAX) : \ + (opus_val32)( 0.5 + (double)(x) * (double)((opus_val32)(1)<<(bits))) ) + #ifdef FIXED_DEBUG #include "fixed_debug.h" #else diff --git a/celt/fixed_debug.h b/celt/fixed_debug.h index f11d890..a479b81 100644 --- a/celt/fixed_debug.h +++ b/celt/fixed_debug.h @@ -49,9 +49,6 @@ extern opus_int64 celt_mips; #define MULT16_32_P16(a,b) MULT16_32_PX(a,b,16) -#define QCONST16(x,bit...

Hi, when I compile with FIXED_DEBUG enabled, I get an error -- both when make tries to build testenc.o and when I try to link my app against the speex lib: lorenz@panelmaker:~/Blackfin/tests/speex_loopthrough$ make bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c bfin-uclinux-gcc -gl -elf2flt -L/home/lorenz/lib -o spe...

...OK, a few things got accidentally broken. I've partially fixed it in svn/git (the limitation is that you can't link with both libspeex and libspeexdsp if configured as fixed-point debug). Can you compile/test now? Jean-Marc Frank Lorenz a ?crit : > Hi, > > when I compile with FIXED_DEBUG enabled, I get an error -- both when make tries to build testenc.o and when I try to link my app against the speex lib: > > > lorenz@panelmaker:~/Blackfin/tests/speex_loopthrough$ make > bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c > bfin-uclinux-gcc -gl -elf2flt...

...artially fixed it in > svn/git (the limitation is that you can't link with both libspeex and > libspeexdsp if configured as fixed-point debug). > > Can you compile/test now? > > Jean-Marc > > Frank Lorenz a ?crit : >> Hi, >> >> when I compile with FIXED_DEBUG enabled, I get an error -- both >> when make tries to build testenc.o and when I try to link my app >> against the speex lib: >> >> >> lorenz at panelmaker <http://lists.xiph.org/mailman/listinfo/speex-dev> :~/Blackfin/tests/speex_loopthrough$ make >> bf...

...define LPC_SCALING 8192 #define SIG_SCALING 16384 #define LSP_SCALING 8192. #define GAMMA_SCALING 32768. #define GAIN_SCALING 64 #define GAIN_SCALING_1 0.015625 #define LPC_SHIFT 13 #define SIG_SHIFT 14 #define VERY_SMALL 0 #ifdef ARM_ASM #include "fixed_arm.h" #elif defined (FIXED_DEBUG) #include "fixed_debug.h" #else #include "fixed_generic.h" #endif #else typedef float spx_mem_t; typedef float spx_coef_t; typedef float spx_lsp_t; typedef float spx_sig_t; typedef float spx_word16_t; typedef float spx_word32_t; typedef float spx_word64_t; #define LPC_SCALI...

...wn "fixed_xx.h" header file. I don't know why, and haven't > had time to investigate, but there is a definite improvement when I use the > attached fixed_c55x.h file which has turned all the maths into inline > functions. Did you try with fixed_generic.h or just with fixed_debug.h? fixed_debug.h uses int and short directly, so I know it won't work with the C5x. However, I think fixed_generic.h should work and has all the operators defined as macros anyway, so inlining isn't a problem. > Some optimisation or something is probably possible here to > reduce co...

...icant, > so it looks like some processing may have been simplified too much. Actually, there's been some major optimization between 1.1.6 and 1.1.8. Most of that was just before 1.1.7. As for a possible cause, it's hard to tell. Here's a couple things I would suggest: - Try defining FIXED_DEBUG and see if you have overflows (you'll probably have to tweak fixed_debug.h first because it assumes int=32 bits) - Try adding a "#define int long" or something like that in the C files. - Since you're saying that the decoder is having the problem too (when the file is correctly en...

...ar 2010 um 16:39 geschrieben: > Yes, I did. > > As mentioned earlier, only the enhancer inside the docoder produces a lot of overflow messages (it points to lines 68 and 69 inside ltp.c). When I turn the enhancer of (via SPEEX_SET_ENH control), the codec runs without any messages from the FIXED_DEBUG thing, regardless if the output signal is o.k. or not. > > best regards, > Frank > > Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> hat am 16. Januar 2010 um 01:41 geschrieben: > > > Did you run the encoder with the fixed-point debug option? > > > >...

...;1" needs a cast: > > #define PSHR32(a,shift) (SHR32((a)+((EXTEND32(1)<<((shift))>>1)),shift)) > > This change fixed the warning, and it did change the assembled code. > With the original file, the ((1<<((shift))>>1)) was optimized away. > Note that fixed_debug.h has the same problem. > > - Jim > > ----- Original Message ----- From: "Jean-Marc Valin" > <jean-marc.valin@usherbrooke.ca> > To: "Jim Crichton" <jim.crichton@comcast.net> > Cc: <speex-dev@xiph.org>; "Michael Jacobson" > &l...

Hi Jean-Marc, Based on the wonderful Speex project, I've created SpeexOutLoud, essentially a Speex codec port for Windows Mobile 2003 devices. I've included a sample project intended to show the usage of SpeexOutLoud codec in a Pocket PC application based on .NET Compact Framework. I'd request you to please go through the attached build, and include it as a contribution to the

We are in the process over the next week to implement the Fixed Point algorithms into a 200 MHz ARM9 CPU with MMU and I was wondering if you had any experience/knowledge with possible pitfalls. We are running Fixed Point compilation on PC based system (P4 processor) and are noticing that the audio gets "noisy" and then comes back to a more normal voice. Are you aware of any issues with

...e frame loss (i.e. pass a null pointer to speex_decode_int as second parameter for just one frame), the decoder starts to freak out a second later: It produces horrible noise with 0 dBFS. This horrible noise will not vanish until you turn off the input signal. I did some investigation on this with FIXED_DEBUG. The error messages are (lots of this): ADD32: output is not int: 1702286034 in ltp.c: line 68 ADD32: output is not int: 1455757562 in ltp.c: line 69 Call stack for this (only set the break point once, may be there are other call stacks on error, too): sb_decode ( ) at sb_celp.c:898 nb_decode (...

...e frame loss (i.e. pass a null pointer to speex_decode_int as second parameter for just one frame), the decoder starts to freak out a second later: It produces horrible noise with 0 dBFS. This horrible noise will not vanish until you turn off the input signal. I did some investigation on this with FIXED_DEBUG. The error messages are (lots of this): ADD32: output is not int: 1702286034 in ltp.c: line 68 ADD32: output is not int: 1455757562 in ltp.c: line 69 Call stack for this (only set the break point once, may be there are other call stacks on error, too): sb_decode ( ) at sb_celp.c:898 nb_decode ( )...

...ble-float-api Disable the floating-point API], [if test "$enableval" = no; then AC_DEFINE([DISABLE_FLOAT_API], , [Disable all parts of the API that are using floats]) @@ -198,7 +228,7 @@ AC_ARG_ENABLE(fixed-point-debug, [ --enable-fixed-point-debug Debug fixed-poin AC_DEFINE([FIXED_DEBUG], , [Debug fixed-point implementation]) fi]) -AC_ARG_ENABLE(resample-full-sinc-table, [ --enable-resample-full-sinc-table Resample full SINC table], +AC_ARG_ENABLE(resample-full-sinc-table, [ --enable-resample-full-sinc-table Resample full SINC table (no interpolation)], [if test "$enabl...

...br />> frame), the decoder<br />> starts to freak out a second later: It produces horrible noise with 0 dBFS.<br />> This<br />> horrible noise will not vanish until you turn off the input signal.<br />><br />> I did some investigation on this with FIXED_DEBUG. The error messages are<br />> (lots<br />> of this):<br />> ADD32: output is not int: 1702286034 in ltp.c: line 68<br />> ADD32: output is not int: 1455757562 in ltp.c: line 69<br />><br />> Call stack for this (only set the break point once, m...

Yes, I did. As mentioned earlier, only the enhancer inside the docoder produces a lot of overflow messages (it points to lines 68 and 69 inside ltp.c). When I turn the enhancer of (via SPEEX_SET_ENH control), the codec runs without any messages from the FIXED_DEBUG thing, regardless if the output signal is o.k. or not. best regards, Frank Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> hat am 16. Januar 2010 um 01:41 geschrieben: > Did you run the encoder with the fixed-point debug option? > > Jean-Marc > > On 2010-01-14 11...

...pass a null pointer to speex_decode_int as second parameter for just one frame), the decoder > starts to freak out a second later: It produces horrible noise with 0 dBFS. This > horrible noise will not vanish until you turn off the input signal. > > I did some investigation on this with FIXED_DEBUG. The error messages are (lots > of this): > ADD32: output is not int: 1702286034 in ltp.c: line 68 > ADD32: output is not int: 1455757562 in ltp.c: line 69 > > Call stack for this (only set the break point once, may be there are other call > stacks on error, too): > > sb_dec...

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: maleout12may.wav Type: audio/wav Size: 95884 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20050524/57112d0c/maleout12may-0001.bin

...o fit in 16 bits) > > Note that all these functions DO NOT perform saturation, so you need to > make sure that the operations can't possibly overflow (or use the > SATURATE macro, but preferably not). A good thing to do is to configure > with --enable-fixed-point-debug (or define FIXED_DEBUG) and test with > several files and look at differences between floating point and fixed > point. > > Jean-Marc > > -- > Jean-Marc Valin > http://www.xiph.org/~jm/ > LABORIUS > Université de Sherbrooke, Québec, Canada --- >8 ---- List archives: http://www.xiph.or...

.... I don't know why, and >> haven't >> had time to investigate, but there is a definite improvement when I use >> the >> attached fixed_c55x.h file which has turned all the maths into inline >> functions. > > Did you try with fixed_generic.h or just with fixed_debug.h? > fixed_debug.h uses int and short directly, so I know it won't work with > the C5x. However, I think fixed_generic.h should work and has all the > operators defined as macros anyway, so inlining isn't a problem. I incorporated Stuarts fixed_c55x.h file, and that eliminated the...