search for: spx_uint16_t

...PES_H__ #define __SPEEX_TYPES_H__ -#if defined HAVE_STDINT_H -# include <stdint.h> -#elif defined HAVE_INTTYPES_H -# include <inttypes.h> -#elif defined HAVE_SYS_TYPES_H -# include <sys/types.h> -#endif + at INCLUDE_STDINT@ typedef @SIZE16@ spx_int16_t; typedef @USIZE16@ spx_uint16_t; -- 2.1.4

Hi Ted, Thanks a lot for this analysis. > In FLOAT_DIVU() it hangs at the following: > while (a.m >= b.m) > { > e++; > a.m >>= 1; > } > for the case where a and b are both zero (yes, division by zero). > This happens from mdf.c: True, that needs to be fixed even after I fix the rest. > leak_estimate =

...appens when > FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is causing > the result to go negative. I worked around this by changing I think that was mentioned in the previous thread... > return (a.m+(1<<(-a.e-1)))>>-a.e; > to > return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; Is that sufficient to remove all the overflows at this place? > I have not had time to trace this, but it looks like a similar problem, > where the result of MULT16_32_Q15(M_1,r) is negative, and FLOAT_DIV32_FLOAT > bombs. Maybe the best thing t...

...b}. The rounding is causing > >> the result to go negative. I worked around this by changing > > > > I think that was mentioned in the previous thread... > > > >> return (a.m+(1<<(-a.e-1)))>>-a.e; > >> to > >> return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; > > > > Is that sufficient to remove all the overflows at this place? > > The rounding takes the value to exactly 0x8000, and it is followed by a > right shift, so you just need to avoid the sign extension. > > >> I have no...

...mode running natively on the ARM side of the DaVinci without click noise. I only get the clicking noise when running Speex on the DSP side. For the TI C64+ DSP on the DaVinci processor, the TI-specific switches doesn't do much other than defining the different Speex data types (spx_int16_t, spx_uint16_t, spx_int32_t, etc) and the static heap and scratch size (in config.h and speex_types.h). How do I try "generic fixed-point"; is there a MACRO for generic fixed-point like "GENERIC_FIXED_POINT". I guess I could try to see if it's an encoder issue (encode it on the DSP and...

..., which occurs because adapt_rate is < 0, which happens when > FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is causing > the result to go negative. I worked around this by changing > > return (a.m+(1<<(-a.e-1)))>>-a.e; > to > return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; > > in FLOAT_EXTRACT16. This changes the returned value from 0xfc00 to 0x400. > Now it runs on for a while, then hits another infinite loop at mdf.c line > 641: > > st->power_1[i] = > FLOAT_SHL(FLOAT_DIV32_FLOAT(MULT16_32_Q...

...HAVE_STDINT_H > -# include <stdint.h> > -#elif defined HAVE_INTTYPES_H > -# include <inttypes.h> > -#elif defined HAVE_SYS_TYPES_H > -# include <sys/types.h> > -#endif > + at INCLUDE_STDINT@ > > typedef @SIZE16@ spx_int16_t; > typedef @USIZE16@ spx_uint16_t; >

...fndef _SPEEX_TYPES_H #define _SPEEX_TYPES_H #if defined(_WIN32) # if defined(__CYGWIN__) # include <_G_config.h> typedef _G_int64_t spx_int64_t; typedef _G_int32_t spx_int32_t; typedef _G_uint32_t spx_uint32_t; typedef _G_int16_t spx_int16_t; typedef _G_uint16_t spx_uint16_t; # elif defined(__MINGW32__) typedef short spx_int16_t; typedef unsigned short spx_uint16_t; typedef int spx_int32_t; typedef unsigned int spx_uint32_t; typedef long long spx_int64_t; typedef unsigned long long spx_uint64_t; # elif defined(__MWERKS__) typedef lo...

...gt; >> the result to go negative. I worked around this by changing > > > > > > I think that was mentioned in the previous thread... > > > > > >> return (a.m+(1<<(-a.e-1)))>>-a.e; > > >> to > > >> return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; > > > > > > Is that sufficient to remove all the overflows at this place? > > > > The rounding takes the value to exactly 0x8000, and it is followed by a > > right shift, so you just need to avoid the sign extension. > &...

...OAT_DIV32 (mdf.c line 660), which occurs because adapt_rate is < 0, which happens when FLOAT_EXTRACT16 gets the input {0x7ff0, 0xfffb}. The rounding is causing the result to go negative. I worked around this by changing return (a.m+(1<<(-a.e-1)))>>-a.e; to return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; in FLOAT_EXTRACT16. This changes the returned value from 0xfc00 to 0x400. Now it runs on for a while, then hits another infinite loop at mdf.c line 641: st->power_1[i] = FLOAT_SHL(FLOAT_DIV32_FLOAT(MULT16_32_Q15(M_1,r),FLOAT_MUL32U(e,st->...

...ACT16 gets the input {0x7ff0, 0xfffb}. The rounding is causing >> the result to go negative. I worked around this by changing > > I think that was mentioned in the previous thread... > >> return (a.m+(1<<(-a.e-1)))>>-a.e; >> to >> return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; > > Is that sufficient to remove all the overflows at this place? The rounding takes the value to exactly 0x8000, and it is followed by a right shift, so you just need to avoid the sign extension. >> I have not had time to trace this, but it lo...

...ng is > >> causing > >> the result to go negative. I worked around this by changing > > > > I think that was mentioned in the previous thread... > > > >> return (a.m+(1<<(-a.e-1)))>>-a.e; > >> to > >> return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; > > > > Is that sufficient to remove all the overflows at this place? > > The rounding takes the value to exactly 0x8000, and it is followed by a > right shift, so you just need to avoid the sign extension. > > >> I have not h...

...mode running natively on the ARM side of the DaVinci without click noise. I only get the clicking noise when running Speex on the DSP side. For the TI C64+ DSP on the DaVinci processor, the TI-specific switches doesn't do much other than defining the different Speex data types (spx_int16_t, spx_uint16_t, spx_int32_t, etc) and the static heap and scratch size (in config.h and speex_types.h). How do I try "generic fixed-point"; is there a MACRO for generic fixed-point like "GENERIC_FIXED_POINT". I guess I could try to see if it's an encoder issue (encode it on the DSP and...

...peex.h:43, from libavcodec/libspeexdec.c:21: /home/user/build/include/speex/speex_config_types.h:12:1: error: unknown type name ?int16_t? typedef int16_t spx_int16_t; ^ /home/user/build/include/speex/speex_config_types.h:13:1: error: unknown type name ?uint16_t? typedef uint16_t spx_uint16_t; ^ /home/user/build/include/speex/speex_config_types.h:14:1: error: unknown type name ?int32_t? typedef int32_t spx_int32_t; ^ /home/user/build/include/speex/speex_config_types.h:15:1: error: unknown type name ?uint32_t? typedef uint32_t spx_uint32_t; ^ In file included from libavcodec/libspee...

...gt; >> the result to go negative. I worked around this by changing > > > > > > I think that was mentioned in the previous thread... > > > > > >> return (a.m+(1<<(-a.e-1)))>>-a.e; > > >> to > > >> return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; > > > > > > Is that sufficient to remove all the overflows at this place? > > > > The rounding takes the value to exactly 0x8000, and it is followed by a > > right shift, so you just need to avoid the sign extension. > &...

...negative. I worked around this by changing > > > > > > > > I think that was mentioned in the previous thread... > > > > > > > >> return (a.m+(1<<(-a.e-1)))>>-a.e; > > > >> to > > > >> return (((spx_uint16_t) a.m)+(1<<(-a.e-1)))>>-a.e; > > > > > > > > Is that sufficient to remove all the overflows at this place? > > > > > > The rounding takes the value to exactly 0x8000, and it is followed by a > > > right shift, so you just need to avoid t...