search for: silk_

...mit_overflow() which is the SMALL_FOOTPRINT branch. The only difference for fixed-point is: celt_fir(): the sum is truncated first and then accumulated to x[i] and saturated. celt_fir_permit_overflow(): x[i] is accumulated to the sum first and then truncated saturated. Maybe this is the reason why silk_LPC_analysis_filter() switched the FIR from celt_fir() to celt_fir_permit_overflow() half a year ago. Because of silk_LPC_analysis_filter(), celt_fir_permit_overflow() must behave the same for both floating-point and fixed-point, and this is why we defined ADD32_FIXED(), ..., PSHR32_FIXED() etc. I...

...se in the SMALL_FOOTPRINT case it first gets shifted up by SIG_SHIFT, the result of the downshift (also by SIG_SHIFT) is the same no matter when it gets added. That being said, I thought adding at the beginning was nicer so I changed the remaining code to do that. > Maybe this is the reason why silk_LPC_analysis_filter() switched the FIR > from celt_fir() to celt_fir_permit_overflow() half a year ago. No, it's another issue. silk_LPC_analysis_filter() was always bit-exact with celt_fir(), with or without SMALL_FOOTPRINT. The only difference lies with the signed integer overflow suppress...

> > I believe the solution would be to always have either: > 1) USE_CELT_FIR=1 and use ovflw() macros in the xcorr code; or > 2) USE_CELT_FIR=0 and no ovflw() in the xcorr code > I prefer to create a function named silk_fir() with optimization to do the calculation when USE_CELT_FIR=0. xcorr_kernel() itself is great and provides many gains. The only issue is that calling it in a for loop makes it less efficient. xcorr_kernel() is called in several functions including celt_fir(), celt_pitch_xcorr() and celt_iir()....