search for: new_c0_calc

...ith a sine wave). - The problem seems to happen when rshifts >= 3 - when pre-scaling the signal to be < 16384 the problem goes away (patch scale_burg_in.diff) - When calculating C0 and rshifts based on a 64 bits correlation instead of using silk_sum_sqr_shift the problem also goes away (patch new_C0_calc.diff) I suspect that for very high prediction gain the fixed point implementation becomes very sensitive to numerical error, but I am not too sure why the new versions work better. I favour the version with the new C0 calculation, as it avoids rescaling the input. I also played around with a versi...

Hi, Apologies if this is a known issues, but I have found what I believe is a bug in the fixed point implementation of the Silk codec and could not find any mention on this in the archives. The bug can be easily reproduced with the fixed point demo program (./configure ?enable-fixed-point ?disable-float-api && make) using the following command: ./opus_demo voip 16000 1 23000

...en when rshifts >= 3 >> - when pre-scaling the signal to be < 16384 the problem goes away (patch >> scale_burg_in.diff) >> - When calculating C0 and rshifts based on a 64 bits correlation instead >> of using silk_sum_sqr_shift the problem also goes away (patch >> new_C0_calc.diff) >> >> I suspect that for very high prediction gain the fixed point >> implementation becomes very sensitive to numerical error, but I am not >>too >> sure why the new versions work better. >> I favour the version with the new C0 calculation, as it avoids r...

...roblem seems to happen when rshifts >= 3 > - when pre-scaling the signal to be < 16384 the problem goes away (patch > scale_burg_in.diff) > - When calculating C0 and rshifts based on a 64 bits correlation instead > of using silk_sum_sqr_shift the problem also goes away (patch > new_C0_calc.diff) > > I suspect that for very high prediction gain the fixed point > implementation becomes very sensitive to numerical error, but I am not too > sure why the new versions work better. > I favour the version with the new C0 calculation, as it avoids rescaling > the input. &gt...

...roblem seems to happen when rshifts >= 3 > - when pre-scaling the signal to be < 16384 the problem goes away (patch > scale_burg_in.diff) > - When calculating C0 and rshifts based on a 64 bits correlation instead > of using silk_sum_sqr_shift the problem also goes away (patch > new_C0_calc.diff) > > I suspect that for very high prediction gain the fixed point > implementation becomes very sensitive to numerical error, but I am not too > sure why the new versions work better. > I favour the version with the new C0 calculation, as it avoids rescaling > the input. &gt...

...= 3 >>> - when pre-scaling the signal to be < 16384 the problem goes away (patch >>> scale_burg_in.diff) >>> - When calculating C0 and rshifts based on a 64 bits correlation instead >>> of using silk_sum_sqr_shift the problem also goes away (patch >>> new_C0_calc.diff) >>> >>> I suspect that for very high prediction gain the fixed point >>> implementation becomes very sensitive to numerical error, but I am not >>> too >>> sure why the new versions work better. >>> I favour the version with the new C0 cal...

...aling the signal to be < 16384 the problem goes away > (patch > >>> scale_burg_in.diff) > >>> - When calculating C0 and rshifts based on a 64 bits correlation > instead > >>> of using silk_sum_sqr_shift the problem also goes away (patch > >>> new_C0_calc.diff) > >>> > >>> I suspect that for very high prediction gain the fixed point > >>> implementation becomes very sensitive to numerical error, but I am not > >>> too > >>> sure why the new versions work better. > >>> I favour t...