search for: float_extract16

...t 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 = FLOAT_EXTRACT16(FLOAT_SHL(FLOAT_DIVU(st->Pey, st->Pyy),14)); > where st->Pey and st->Pyy are both zero, which happens for the following input > data to testecho program: > -- first arg is file containing sine wave of magnitude +/- 32767 > -- 2nd arg is file containing all zeroes > >...

...lock size=128, tail length = 1024), and I will probably not be > able to fit it in the production build without some trimming. > > When I run the build, it goes into an infinite loop in FLOAT_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. T...

...namic data memory for block size=128, tail length = 1024), and I will probably not be able to fit it in the production build without some trimming. When I run the build, it goes into an infinite loop in FLOAT_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...

...reduction possible here. Of course, > > decreasing the tail length is also a rather easy way. > > > >> When I run the build, it goes into an infinite loop in FLOAT_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 > > > > I think that was mentioned in the previous thread... > > > >> return (a.m+(1<<(-a.e-1)))>>-a.e; > >> to...

> I am writing to gain a better understanding of the limitations of speex echo > cancellation, esp. with respect to the fixed point implementation. > If these limitations have been documented elsewhere already, please let me > know! Nothing officially documented, sorry. > I observe experimentally that when one or both of the echo or ref data for > speex_echo_cancel() have

...; > decreasing the tail length is also a rather easy way. > > > > > >> When I run the build, it goes into an infinite loop in FLOAT_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 > > > > > > I think that was mentioned in the previous thread... > > > > > >> return (a.m+(1<...

...trimming. Yes, there may be a bit of memory reduction possible here. Of course, decreasing the tail length is also a rather easy way. > When I run the build, it goes into an infinite loop in FLOAT_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 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....

...re may be a bit of memory reduction possible here. Of course, > decreasing the tail length is also a rather easy way. > >> When I run the build, it goes into an infinite loop in FLOAT_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 > > I think that was mentioned in the previous thread... > >> return (a.m+(1<<(-a.e-1)))>>-a.e; >> to >> return (((spx_u...

Thanks for your prompt and helpful reply. 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: leak_estimate = FLOAT_EXTRACT16(FLOAT_SHL(FLOAT_DIVU(st->Pey, st->Pyy),14)); where st->Pey and st->Pyy are both zero, which happens for the following input data to testecho program: -- first arg is file containing sine wave of magnitude +/- 32767 -- 2nd arg is file containing all zeroes The division by zero appears...

...ible here. Of course, > > decreasing the tail length is also a rather easy way. > > > >> When I run the build, it goes into an infinite loop in FLOAT_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 > > > > I think that was mentioned in the previous thread... > > > >> return (a.m+(1<<(-a.e-1)))>>-a.e; &g...

...t; > decreasing the tail length is also a rather easy way. > > > > > >> When I run the build, it goes into an infinite loop in FLOAT_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 > > > > > > I think that was mentioned in the previous thread... > > > > > >> return (a.m+(1<&...

...il length is also a rather easy way. > > > > > > > >> When I run the build, it goes into an infinite loop in FLOAT_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 > > > > > > > > I think that was mentioned in the previous thread... > > > > > > > >...