search for: extend32

...ined the follow error: "Error: Can not represent OFFSET_IMM8 relocation in this object file format (1)" I have defined FIXED_POINT 1 and ARM4_ASM. The error is in the function forced_pitch_quant contained in ltp.c. The line that produce the error is: target[i]=EXTRACT16(SATURATE(SUB32(EXTEND32(target[i]),EXTEND32(res[i])),32700)); Why this error??? In the emulator i have no problem. I resolved with the sequent workaround: spx_word16_t tmp = EXTRACT16(SATURATE(SUB32(EXTEND32(target[i]),EXTEND32(res[i])), 32700)); target[i] = tmp; Now i can compile e linking the lib in my application....

...> nb_mode, QCONT16(.0002,15) evaluates to 0x3FF9 on the C55 and 0x4006 on the > C6x. When I patch the value 0x4006 into the C55 build, the output matches > the C6x. The problem is that 2^15 evaluates to -32768 on the C55 and 32768 > on the C6x. Right on! > Applying our friend EXTEND32 causes the constant to evaluate correctly. In > fixed_generic.h, > #define QCONST16(x,bits) > ((spx_word16_t)((x)*((EXTEND32(1))<<(bits))+((EXTEND32(1))<<((bits)-1)))) Actually, this is a case for a simple cast to (spx_word32_t) because QCONST can be used in a static initia...

...h file would >> > work because the inline function would first force the conversion to 32 >> > bits. My initial guess would be with the SH[RL]32 and ADD32 functions. Nice call. The culprit is SHRL32. This is not used in many places, and in most of those, the operand comes from EXTEND32. The only really suspicious instances is in lsp.c (lsp_interpolate): spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); (subframe is an int) > I just checked in changes that may fix some bad behavior on 16-bit > architectures. You might want to try if it fixes the probl...

...the C55 and 0x4006 on >> the >> C6x. When I patch the value 0x4006 into the C55 build, the output >> matches >> the C6x. The problem is that 2^15 evaluates to -32768 on the C55 and >> 32768 >> on the C6x. > >Right on! > >> Applying our friend EXTEND32 causes the constant to evaluate correctly. >> In >> fixed_generic.h, >> #define QCONST16(x,bits) >> ((spx_word16_t)((x)*((EXTEND32(1))<<(bits))+((EXTEND32(1))<<((bits)-1)))) > >Actually, this is a case for a simple cast to (spx_word32_t) because >QCONST...

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 Jim, > Build 11169 in SVN works correctly. Good. I'll try not to forget the EXTEND32 from now on. > I have attached a zip file (renamed > .txt) with a patch to bits.c to make the byteswapping for TI DSPs > consistent. Seems like unzip can't read it. Either it's in an unknown format or the file got corrupted. Could simply send as multiple (uncompressed) attach...

Jean-Marc, >> Build 11169 in SVN works correctly. > > Good. I'll try not to forget the EXTEND32 from now on. > >> I have attached a zip file (renamed >> .txt) with a patch to bits.c to make the byteswapping for TI DSPs >> consistent. > > Seems like unzip can't read it. Either it's in an unknown format or the > file got corrupted. Could simply send as mult...

...anceller 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)." >> >> Yes, I remember those and I'm pretty sure they're fixed now. I think the >> problem comes from other changes I made later on, but I can't unders...

Hello, I've just caught a strange crash in speex_echo_state_init routine. It happened only on one WinXP machine, while on others using XP, Vista and 7 everything is fine. Crash occures in mdf.c line 434: st->spec_average = DIV32_16(SHL32(EXTEND32(st->frame_size), 15), st->sampling_rate); Got any ideas or should I provide more information of the OS? Thanks a lot! Regards, Anton A. Shpakovsky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachment...

...: > 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)." Yes, I remember those and I'm pretty sure they're fixed now. I think the problem comes from other changes I made later on, but I can't understand what's wrong. > I sen...

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

...it out. Could you try changing the definition of SHL32 in fixed_generic.h from #define SHR32(a,shift) ((a) >> (shift)) to #define SHR32(a,shift) (((spx_word32_t)(a)) >> (shift)) This is not the correct fix, but if it does solve the problem, then I know how to fix it properly (by using EXTEND32) in svn. > It may be a compiler hiccup in scaling/shifting, or else somehow the pointer > to the data has been trashed. I tried scaling the input data up by a factor > of 10, and this affected the output, but it is still just low amplitude > noise. I will look some more tomorrow....

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

...s 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 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 Va...

> Nice call. The culprit is SHRL32. This is not used in many places, and in > most of those, the operand comes from EXTEND32. The only really suspicious > instances is in lsp.c (lsp_interpolate): > > spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); > (subframe is an int) > ... > I see that your changes include adding an EXTEND32 to the line above. I > made ONLY this change t...

...n was broken again. I traced this to build 11522, committed on 5 June. The problem is in lsp.c, function lsp_to_lpc(). The line (lsp.c line 461 in build 11700): xin = 1<<(QIMP-1); /* 0.5 in QIMP format */ evaluates to zero. The following change corrects the problem: xin = SHL32(EXTEND32(1), (QIMP-1)); /* 0.5 in QIMP format */ Regards, Jim Crichton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20060724/03c37193/attachment.htm

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 a patch with some fixes later that month, but I have not built the echo canceller since then (no room for it). It is very likely that you are seeing the same issue, and the fix should...

...When I get a chance, I will add some > instrumentation and see if I can find where things diverge. Just looking at > the canceled audio files with a waveform editor, they were not obviously > different, so it is not a burning issue for me. Try updating svn again. I just found out that EXTEND32() and EXTRACT16() were actually unsafe due to a pair of () missing around the argument. I also fixed a few minor things. Tell me if it works now. Jean-Marc

>> Nice call. The culprit is SHRL32. This is not used in many places, and >> in >> most of those, the operand comes from EXTEND32. The only really >> suspicious >> instances is in lsp.c (lsp_interpolate): >> >> spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); >> (subframe is an int) >> ... >> I see that your changes include adding an EXTEND32 to the line above....

...efly 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)." > > Yes, I remember those and I'm pretty sure they're fixed now. I think the > problem comes from other changes I made later on, but I can't understand > what...