search for: div32_16

...+++ libspeex/preprocess.c (arbetskopia) > > @@ -1126,16 +1126,16 @@ > > break; > > > > case SPEEX_PREPROCESS_SET_PROB_START: > > - *(spx_int32_t*)ptr = MIN32(Q15_ONE,MAX32(0, *(spx_int32_t*) > > ptr)); > > - st->speech_prob_start = DIV32_16(MULT16_16(32767,* > > (spx_int32_t*)ptr), 100); > > + *(spx_int32_t*)ptr = MIN32(100,MAX32(0, *(spx_int32_t*)ptr)); > > + st->speech_prob_start = DIV32_16(MULT16_16(Q15ONE,* > > (spx_int32_t*)ptr), 100); > > break; > > case SPEEX_PREPROC...

Hi, I tried to figure out what the problem is -- but it seems to be totally different from what I expected. My status at the moment is: - computing results for "generic" and "Blackfin ASM" versions of the DIV32_16 function are the same, there is no "algorithmic bug" - Instead, there seems some sort of memory corruption: When I comment out the DIV32_16 function inside "fixed_bfin.h", everything works fine. When I replace the DIV32_16 function inside "fixed_bfin.h" with a func...

...=========================== --- libspeex/preprocess.c (revision 13983) +++ libspeex/preprocess.c (arbetskopia) @@ -1126,16 +1126,16 @@ break; case SPEEX_PREPROCESS_SET_PROB_START: - *(spx_int32_t*)ptr = MIN32(Q15_ONE,MAX32(0, *(spx_int32_t*)ptr)); - st->speech_prob_start = DIV32_16(MULT16_16(32767,*(spx_int32_t*)ptr), 100); + *(spx_int32_t*)ptr = MIN32(100,MAX32(0, *(spx_int32_t*)ptr)); + st->speech_prob_start = DIV32_16(MULT16_16(Q15ONE,*(spx_int32_t*)ptr), 100); break; case SPEEX_PREPROCESS_GET_PROB_START: (*(spx_int32_t*)ptr) = MULT16_16_Q15(...

...ta' within 'speex_preprocess_run', I received a floating point exception even when compiled with -DFIXED_POINT. The reason is as follows: <original beta calculation within speex_preprocess_run> ... st->nb_adapt++; st->min_count++; beta = MAX16(QCONST16(.03,15),DIV32_16(Q15_ONE,st->nb_adapt)); beta_1 = Q15_ONE-beta; ... </> On my architecture(x86) at least the DIV32_16 is defined as follows. typedef short spx_int16_t; typedef spx_int16_t spx_word16_t; #define DIV32_16(a,b) ((spx_word16_t)(((spx_word32_t)(a))/((spx_word16_t)(b)))) The nb_adapt overfl...

Hi, I just started to examine the DIV32_16 function (Blackfin ASM version), and wondered why the return value of the function inside 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable 'res' which is returned by this function is of type 'spx_word32_t'. Is this a trick of optimization or a bug? (S...

...cess.c (arbetskopia) >>> @@ -1126,16 +1126,16 @@ >>> break; >>> >>> case SPEEX_PREPROCESS_SET_PROB_START: >>> - *(spx_int32_t*)ptr = MIN32(Q15_ONE,MAX32(0, *(spx_int32_t*) >>> ptr)); >>> - st->speech_prob_start = DIV32_16(MULT16_16(32767,* >>> (spx_int32_t*)ptr), 100); >>> + *(spx_int32_t*)ptr = MIN32(100,MAX32(0, *(spx_int32_t*)ptr)); >>> + st->speech_prob_start = DIV32_16(MULT16_16(Q15ONE,* >>> (spx_int32_t*)ptr), 100); >>> break; >>> ca...

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

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

...eex-dev] Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation??? Frank Lorenz a ?crit : > Yes, this is another point: I wrote that the resampler breaks, but > this is not the case. Instead, the speex encoder corrupts its input > buffer when the "DIV32_16 bug" described above happens. Do you have > any idea how to proceed? Can you try enabling --enable-fixed-point-debug (FIXED_DEBUG) and see if any error gets printed. I suspect there might be a place where the assumptions of DIV32_16 are violated, i.e. either the right hand side doesn't...

...fin assembly optimizations -- bug in fixed_bfin.h / resampler saturation??? > > > Frank Lorenz a ?crit : >> Yes, this is another point: I wrote that the resampler breaks, but >> this is not the case. Instead, the speex encoder corrupts its input >> buffer when the "DIV32_16 bug" described above happens. Do you have >> any idea how to proceed? > > Can you try enabling --enable-fixed-point-debug (FIXED_DEBUG) and see if > any error gets printed. I suspect there might be a place where the > assumptions of DIV32_16 are violated, i.e. either the rig...

Frank Lorenz a ?crit : > And yes, the same "overflow" happens even when I disable Blackfin ASM > optimizations. Indeed, that shouldn't happen. Just to make sure I understand, so far there's two problems: 1) DIV32_16() in Blackfin assembly causes problems 2) The resampler overflows When you fix/workaround those two, is the encoder/decoder working correctly or are there other issues? About the DIV32_16() issue, could you try and replace it with a function that compares the Blackfin-asm result with the real div...

...>> in fixed_bfin.h / resampler saturation??? >> >> >> Frank Lorenz a ?crit : >>> Yes, this is another point: I wrote that the resampler breaks, >>> but this is not the case. Instead, the speex encoder corrupts its >>> input buffer when the "DIV32_16 bug" described above happens. Do >>> you have any idea how to proceed? >> Can you try enabling --enable-fixed-point-debug (FIXED_DEBUG) and >> see if any error gets printed. I suspect there might be a place >> where the assumptions of DIV32_16 are violated, i.e. eith...

Hi Jean-Marc, didn't get a reply to my last post (see below) -- do you have no idea what happens here? After some more tests, I disabled the DIV32_16 Blackfin optimizations and now get good quality on the Blackfin. But when I have overdrive on the input, things become very bad -- I'm not sure if this is really a filter stability issue like I wrote some weeks ago. I use the speex resampler to downsample from 48 to 16 kHz. When I look to the...

...> > 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 problem. As I said, > it's not clear yet whether the problem is in fixed_generic.h or if it's &gt...

...;s reflection 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 q...

Hi Jean-Marc, I did some further checks with 1.2 beta 3: The problematic function is DIV32_16 inside fixed_bfin.h. When I comment it out (i.e. replace it by the generic version of the routine), the quality improves significantly. Nevertheless, there is still a horrible distortion when there is some overdrive/saturation in the input signal. For me, it looks like there's an instable filte...

...t;A1 = A1 >>> 15;\n\t" "%0 = (A1 += %2.L*%1.H);\n\t" "%0 = %0 + %4;\n\t" : "=&W" (res), "=&d" (b) : "d" (a), "1" (b), "d" (c) : "A1" ); return res; } #undef PDIV32_16 static inline celt_int16 PDIV32_16(celt_int32 a, celt_int16 b) { celt_int32 res, bb; bb = b; a += b>>1; __asm__ ( "P0 = 15;\n\t" "R0 = %1;\n\t" "R1 = %2;\n\t" //"R0 = R0 + R1;\n\t" "R0 <&...

> 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 to the 1.1.8 base that I am working from, and the > problem is gone. Good. So I guess you are still having your lo...

...speex-dev at xiph.org Subject: [Speex-dev] AEC init crashes 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...

>> 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 to the 1.1.8 base that I am working from, and the >> problem is gone. > > Good. So I guess yo...