We got a crash issue reported from the deployment in the field in GSM AMR encoder using Intel IPP.
We are able to easily reproduce this issue with a 30 frame voice clip.
The crash is happening in function ippsAlgebraicCodebookSearch_GSMAMR_16s. After back tracing the crash, we found that the issue happened because of invalid T0 and gain_pit values. So we analyzed the difference in bit exactness, and followed the trail, and found that it is originating in the function ippsLPCToLSP_GSMAMR_16s.
If we replace this IPP function (ippsLPCToLSP_GSMAMR_16s) with its original standard reference code function (Az_lsp), we are getting bit exact results and ofcourse no crash! Unfortunately the computation required for this function Az_lsp is extremely huge, and cannot be used in our product in the field, which will have capacity hit, which will make it unusable.
We are using IPP version 7.1
1. Are there any known issue with the function ippsLPCToLSP_GSMAMR_16s? And any fix available for this?
2. Is there any equivalent function for this IPP function which are optimized as good as this function?
3. Is there a way we can get source code of the function ippsLPCToLSP_GSMAMR_16s, so that we could try to fix the issue ourselves?
Appreciate any help.
Thanks and regards,
ippsLPCToLSP_GSMAMR_16s has been deprecated since IPP 8, and the functions in speech codec domain are deprecated and no longer supported in IPP 9.0. However, you can still download the legacy libraries here https://software.intel.com/en-us/articles/intel-ipp-legacy-libraries, but those functions will not be optimized for future architectures. Thanks!
do you have the information on where the function hang? It was noticed an issues that the function internally hangs on inw7_ownSearchOptimalPulsePos_M122_GSMAMR_16s_optSSE?
Not sure if this is the same problem with yours
#0 0x07b2bcfe inw7_ownSearchOptimalPulsePos_M122_GSMAMR_16s_optSSE () from /usr/lib/libippscw7.so.7.1 #1 0x07b1e348 inw7_ownAlgebraicCodebookSearch_M122_GSMAMR_16s () from ........
Yes, this is the problem that we are facing. We're debugging under Windows but we're also working with Linux and it also hangs (but we did not check if stuck at the same place) It hangs in the routine you mentioned.
CALL STACK REPORT:
ownSearchOptimalPulsePos_M122_GSMAMR_16s_optSSE() (** LOOPS IN HERE)
Do you have a fix or any idea on how to resolve this?
Thanks and regards,
I mentioned earlier that it does not fail with an earlier version of the host code. The reason is that this earlier code is NOT calling the function "ippInit()" which is the very first IPP routine that is being used in the program flow. If we add the call to ippInit() or IppStaticInit() then even the earlier code fails and hangs at the same place.
The hang happens with IPP version 7.1.1 and all the 8.x.x that we've tried but does not happen with IPP version 7.0.205. We cannot use the latter because it does not support the resampling routines that we need.
Again, any information is welcomed.
cpu type is
ippCpuAVX = 0x46, /* Processor supports Intel(R) Advanced Vector Extensions (Intel(R) AVX) instruction set */
I tried more cpu types as such:
//IppStatusValue = ippInit(); / this fails (hangs in ownSearchOptimalPulsePos_M122_GSMAMR_16s_optSSE)
cpuType = ippGetCpuType(); // cpuType is ippCpuAVX
cpuType = ippCpuSSE2;
IppStatusValue = ippInitCpu(cpuType);
When overriding cpuType with
ippCpuSSE - does NOT hang
ippCpuSSE2 - does NOT hang
ippCpuSSE3 - hangs in ownSearchOptimalPulsePos_M122_GSMAMR_16s_optSSE()
ippCpuSSSE3 - hangs in ownSearchOptimalPulsePos_M122_GSMAMR_16s_optSSE()
ippCpuAVX- hangs in ownSearchOptimalPulsePos_M122_GSMAMR_16s_optSSE()