search for: extract16

...ARM platform i have obtained 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...

Hi, It is better to replace this line in function filterbank_new: max_mel = toBARK(EXTRACT16(MULT16_16_Q15(QCONST16(.5f,15),sampling))); to max_mel = toBARK(EXTRACT16(sampling/2)); It gives the same but it seems to be faster and avoids overflow on 44100 kHz that prevents denoiser to process 44100 streams. (Yes I know that Speex should not pack 44100 streams but it does now and I use it)...

...buffer) is gone in this configuration. But nevertheless, when I try to encode an overdriven (saturated) signal, the strange toggling between -MAX and MAX values on a sample-by-sample basis still happens. The debug output for this is as follows: SHL16: output is not short: 36500 in ltp.c: line 649 EXTRACT16: input is not short: 33074 in nb_celp.c: line 802 EXTRACT16: input is not short: 37708 in nb_celp.c: line 802 EXTRACT16: input is not short: 43003 in nb_celp.c: line 802 SHL16: output is not short: 34824 in ltp.c: line 649 SHL16: output is not short: -33354 in ltp.c: line 649 SHL16: output is not s...

...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] = EXTRACT16(PSHR32(st->W[j*N+i],NORMALIZE_SCALEDOWN+16)); Is there some kind of switch I was supposed to throw to not get these messages? if not-are they hurting anything? -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/atta...

...n/libspeex/mdf.c impulse_scale/libspeex/mdf.c --- clean/libspeex/mdf.c 2008-02-13 11:12:13.000000000 +0100 +++ impulse_scale/libspeex/mdf.c 2008-02-13 22:47:44.000000000 +0100 @@ -1180,13 +1180,13 @@ { #ifdef FIXED_POINT for (i=0;i<N;i++) - st->wtmp2[i] = EXTRACT16(PSHR32(st->W[j*N+i],16)); + st->wtmp2[i] = EXTRACT16(PSHR32(st->W[j*N+i],16+NORMALIZE_SCALEDOWN)); spx_ifft(st->fft_table, st->wtmp2, st->wtmp); #else spx_ifft(st->fft_table, &st->W[j*N], st->wtmp); #endif for(i=0...

...ance, 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

.... when I filled it with 1's it never worked. I found innov_save will write over memory it shouldn't be when I fill memory with 1's but not when I fill it with zeros. When my DSP gets to this code chunk: if (innov_save){ for (i=0;i<st->subframeSize;i++) innov_save[i] = EXTRACT16(PSHR32(innov[i], SIG_SHIFT)); } it will just start filling data in, which it shouldn't. I see that innov_save is set at the beginning of a for loop at: for (sub=0;sub<st->nbSubframes;sub++) { int offset; spx_word16_t *exc; spx_word16_t *sp; spx_word16_t *innov_...

....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] = EXTRACT16(PSHR32(st->W[j*N+i],NORMALIZE_SCALEDOWN+16)); > > Is there some kind of switch I was supposed to throw to not get these > messages? if not-are they hurting anything? > > -Mike > > > > ------------------------------------------------------------------------ >...

...000f, -1.76000f, 0.88000f}}; #endif const spx_word16_t *den, *num; if (filtID>4) filtID=4; den = Pcoef[filtID]; num = Zcoef[filtID]; /*return;*/ for (i=0;i<len;i++) { spx_word16_t yi; spx_word32_t vout = ADD32(MULT16_16(num[0], x[i]),mem[0]); yi = EXTRACT16(SATURATE(PSHR32(vout,14),32767)); mem[0] = ADD32(MAC16_16(mem[1], num[1],x[i]), SHL32(MULT16_32_Q15(-den[1],vout),1)); mem[1] = ADD32(MULT16_16(num[2],x[i]), SHL32(MULT16_32_Q15(-den[2],vout),1)); y[i] = yi; } } I can step into the function just fine, but when I run it, eve...

...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] = >> EXTRACT16(PSHR32(st->W[j*N+i],NORMALIZE_SCALEDOWN+16)); >> >> Is there some kind of switch I was supposed to throw to not get >> these messages? if not-are they hurting anything? >> >> -Mike >> >> >> >> --------------------------------------------...

...x/filterbank.c Thu Nov 22 14:20:03 2007 @@ -53,7 +53,7 @@ FilterBank *filterbank_new(int banks, spx_word32_t sampling, int len, int type) { - FilterBank *bank; + FilterBank *bnk; spx_word32_t df; spx_word32_t max_mel, mel_interval; int i; @@ -63,16 +63,16 @@ max_mel = toBARK(EXTRACT16(sampling/2)); mel_interval = PDIV32(max_mel,banks-1); - bank = (FilterBank*)speex_alloc(sizeof(FilterBank)); - bank->nb_banks = banks; - bank->len = len; - bank->bank_left = (int*)speex_alloc(len*sizeof(int)); - bank->bank_right = (int*)speex_alloc(len*sizeof(int)); -...

...;>> 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] = >>>> EXTRACT16(PSHR32(st->W[j*N+i],NORMALIZE_SCALEDOWN+16)); >>>> >>>> Is there some kind of switch I was supposed to throw to not get >>>> these messages? if not-are they hurting anything? >>>> >>>> -Mike >>>> >>>> >>&gt...

...nd 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. > > The C55 and C64 builds diverge in exactly the same place as before (byte > 0x1000). The output from C55 build 11387 (svn head) diverges...

...t; 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. The C55 and C64 builds diverge in exactly the same place as before (byte 0x1000). The output from C55 build 11387 (svn head) diverges from C55 build 11343...

...nnov_save will write over memory it shouldn't be when > I fill memory with 1's but not when I fill it with zeros. Which is normal, see below. > When my DSP > gets to this code chunk: > if (innov_save){ > for (i=0;i<st->subframeSize;i++) > innov_save[i] = EXTRACT16(PSHR32(innov[i], SIG_SHIFT)); > } This bit of code is for copying the innov variable to a buffer owned by the wideband decoder -- but only if there is actually a wideband decoder. > it will just start filling data in, which it shouldn't. I see that > innov_save is set at the beginni...

...* st->frame_size; + break; + case SPEEX_ECHO_GET_IMPULSE_RESPONSE: + { + int M = st->M, N = st->window_size, n = st->frame_size, i, j; + spx_int32_t *filt = (spx_int32_t *) ptr; + for(j=0;j<M;j++) + { +#ifdef FIXED_POINT + for (i=0;i<N;i++) + st->wtmp2[i] = EXTRACT16(PSHR32(st->W[j*N+i],16)); + spx_ifft(st->fft_table, st->wtmp2, st->wtmp); +#else + spx_ifft(st->fft_table, &st->W[j*N], st->wtmp); +#endif + for(i=0;i<n;i++) + filt[j*n+i] = PSHR32(MULT16_16(32767,st->wtmp[i]), WEIGHT_SHIFT); + } + } + break; default:...

...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] = EXTRACT16(PSHR32(st->W[j*N+i],NORMALIZE_SCALEDOWN+16)); > > Is there some kind of switch I was supposed to throw to not get these > messages? if not-are they hurting anything? > > -Mike > > > > ------------------------------------------------------------...

...g > 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 hours ago! > Also in the pseudofloat.h is the change to EXTRACT16 which I mentioned > earlier in the thread. The change that I made (casting as unsigned to > prevent MSB extension) solved my problem, but maybe it would be safer to use > EXTEND32 here. That is, after all, the way all of the other 16 bit issues > get solved. I'll need to have...

...eller 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] = >>>>>> EXTRACT16(PSHR32(st->W[j*N+i],NORMALIZE_SCALEDOWN+16)); >>>>>> >>>>>> Is there some kind of switch I was supposed to throw to not get >>>>>> these messages? if not-are they hurting anything? >>>>>> >>>>>> -Mike >&...

...shouldn't be when >> I fill memory with 1's but not when I fill it with zeros. > > Which is normal, see below. > >> When my DSP >> gets to this code chunk: >> if (innov_save){ >> for (i=0;i<st->subframeSize;i++) >> innov_save[i] = EXTRACT16(PSHR32(innov[i], SIG_SHIFT)); >> } > > This bit of code is for copying the innov variable to a buffer owned by > the wideband decoder -- but only if there is actually a wideband decoder. > >> it will just start filling data in, which it shouldn't. I see that >> in...