search for: pshr32

...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: > > #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)&lt...

...sampler_basic_direct_single(SpeexResamplerState *st, spx_uint32_t c sum = accum[0] + accum[1] + accum[2] + accum[3]; */ #else - sum = inner_product_single(sinc, iptr, N); + inner_product_single(&sum, sinc, iptr, N); #endif out[out_stride * out_sample++] = SATURATE32(PSHR32(sum, 15), 32767); @@ -412,7 +412,7 @@ static int resampler_basic_direct_double(SpeexResamplerState *st, spx_uint32_t c } sum = accum[0] + accum[1] + accum[2] + accum[3]; #else - sum = inner_product_double(sinc, iptr, N); + inner_product_double(&sum, sinc, iptr, N); #en...

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

.../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;i<n...

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, .003*ac[0] is added to error, for fixed point, a constant value of 8 is added. When I alter this value, I get an output without "freaking out" for values 1,2,3 and 5. for 4...

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

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

...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, shift), a), but it avoids over flowing in rounding up phase in the rare occasion where x has already been saturated. It should also be slightly faster. --- libspeex/arch.h | 1 + libspeex/fixed_generic.h | 4 ++ libspeex/resample.c | 10 ++++- libspeex/resample_neon.h | 1...

...arning 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/attachments...

...rame_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:...

> On Nov 16, 2015, at 4:42 PM, Jonathan Lennox <jonathan at vidyo.com> wrote: > > I haven?t yet tried replacing SIG2WORD16 (or silk_ADD_SAT32/silk_SUB_SAT32) with Neon intrinsics. That?s an obvious next step. This doesn?t show any appreciable speed difference in my tests, but the code is obviously better by inspection (all three of these map directly to a single Aarch64

...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_save =...

...n coefficient */ spx_word32_t rr = NEG32(SHL32(EXTEND32(ac[i + 1]),13)); for (j = 0; j < i; j++) rr = SUB32(rr,MULT16_16(lpc[j],ac[i - j])); #ifdef FIXED_POINT // stop calculation if error < 30 if ( error <= 30 ) { return error; } //r = DIV32_16(rr+PSHR32(error,1),ADD16(error,10 )); r = DIV32_16(rr+PSHR32(error,1),error); #else r = rr/(error+.003*ac[0]); #endif This improves the situation. There's no more "freak out" for most cases. I tested with 2000 Hz, 2200 Hz and 3000 Hz input for different complexity and quality set...

...size; + break; + case SPEEX_PREPROCESS_GET_PSD: + for(i=0;i<st->ps_size;i++) + ((spx_int32_t *)ptr)[i] = (spx_int32_t) st->ps[i]; + break; + case SPEEX_PREPROCESS_GET_NOISE_PSD: + for(i=0;i<st->ps_size;i++) + ((spx_int32_t *)ptr)[i] = (spx_int32_t) PSHR32(st->noise[i], NOISE_SHIFT); + break; default: speex_warning_int("Unknown speex_preprocess_ctl request: ", request); return -1; -------------- next part -------------- diff -ubBwr get_psd/include/speex/speex_preprocess.h get_prob/include/speex/speex_preprocess.h -...

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

...] += sinc[j+2]*iptr[j+2]; + accum[3] += sinc[j+3]*iptr[j+3]; } - - /* Do the new part */ - if (in != NULL) + sum = accum[0] + accum[1] + accum[2] + accum[3]; +#else + sum = inner_product_single(sinc, iptr, N); +#endif + + out[out_stride * out_sample++] = PSHR32(sum, 15); + last_sample += int_advance; + samp_frac_num += frac_advance; + if (samp_frac_num >= den_rate) { - ptr = in+st->in_stride*(last_sample-N+1+j); - for (;j<N;j++) - { - sum += MULT16_16(*ptr,st->sinc_table[samp_frac_num*st...

...] += sinc[j+2]*iptr[j+2]; + accum[3] += sinc[j+3]*iptr[j+3]; } - - /* Do the new part */ - if (in != NULL) + sum = accum[0] + accum[1] + accum[2] + accum[3]; +#else + sum = inner_product_single(sinc, iptr, N); +#endif + + out[out_stride * out_sample++] = PSHR32(sum, 15); + last_sample += int_advance; + samp_frac_num += frac_advance; + if (samp_frac_num >= den_rate) { - ptr = in+st->in_stride*(last_sample-N+1+j); - for (;j<N;j++) - { - sum += MULT16_16(*ptr,st->sinc_table[samp_frac_num*st...

From: Jyri Sarha <jsarha at ti.com> I optimized Speex resampler for NEON capable ARM CPUs. The first patch should speed up resampling on any platform that can spare the increased memory usage. It would be nice to have these merged to the master branch. Please let me know if there is anything I can do to help the the merge. The patches have been rebased on top of master branch in

...ak; + case SPEEX_PREPROCESS_GET_POWER_SPECTRUM: + for(i=0;i<st->ps_size;i++) + ((spx_int32_t *)ptr)[i] = (spx_int32_t) st->ps[i]; + break; + case SPEEX_PREPROCESS_GET_NOISE_ESTIMATE: + for(i=0;i<st->ps_size;i++) + ((spx_int32_t *)ptr)[i] = (spx_int32_t) PSHR32(st->noise[i], NOISE_SHIFT); + break; + case SPEEX_PREPROCESS_GET_SNR: + { + spx_int32_t fstart = (spx_int32_t) DIV32(MULT16_16(300 * 2, st->ps_size), st->sampling_rate); + spx_int32_t fend = (spx_int32_t) DIV32(MULT16_16(2000 * 2, st->ps_size), st->sampling_rate); + spx_...

>> I think the residual echo estimation is fairly reliable but I do not know >> how to use this to improve Pframe and in that way solve our main problem >> with the gain during near end talk. > > How can you tell that the residual echo estimation is reliable? in any > case, I suspect that the whole Pframe idea might have to be revised > (i.e. computing it completely