search for: scale_burg_in

...seems to be related to silk_burg_modified not reaching the maximum gain, so the actual filter order is 16 rather than 2 (which is what would be expected with 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 sur...

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

...t reaching the >> maximum gain, so the actual filter order is 16 rather than 2 (which is >> what would be expected with 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 v...

...ilk_burg_modified not reaching the > maximum gain, so the actual filter order is 16 rather than 2 (which is > what would be expected with 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 numeric...

...ilk_burg_modified not reaching the > maximum gain, so the actual filter order is 16 rather than 2 (which is > what would be expected with 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 numeric...

...gt;> maximum gain, so the actual filter order is 16 rather than 2 (which is >>> what would be expected with 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 >>> i...

...the actual filter order is 16 rather than 2 (which is > >>> what would be expected with 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...