ippsResamplePolyphase

[rmitchle]

Hi

ippsResamplePolyphase_16s seems to be missing from the 7.01 Linux IPP (64-bit). I have used this in the 6.1 IA32 library.

Can someone from Intel please confirm?

Thanks.

Ryan

[Vladimir_Dudnik]

Hi Ryan,


The ippsResamplePolyphase_16sfunction was available in IPP Speech Recognition domain libray, which was excluded from IPP 7.0 product.

Could you please provide more information in term of what kind of application you are working on, what other IPP functions you may use from this deprecated library, how this functionality is critical for your application needs?

Regards,
Vladimir

[rmitchle]

Hi Vladimir

I would like, firstly, to express my extreme disappointment at Intel deciding to exclude functions from a well known and utilized library. Refactoring or altering functions is one thing, but removing functionality makes professional software development challenging, to say the least.

This is the principal function we use in the Speech Recognition library. It is used to resample audio coming over a network, where there is a fundamental clock mismatch between the data generated on one PC and the sound card performing output of this data on a different PC. The resample function allowed on-the-fly adjustment of resampling ratio (libsamplerate a.k.a. Secret Rabbit Code is equivalent GPL code).

Regards,

Ryan

[rmitchle]

Vladimir,

Can you confirm that there are no equivalent functions in the IPP 7.0 library that will perform polyphase resampling with an arbitrary resampling ratio, alterable on the fly?

If not, what are Intel's plans regarding re-introducing equivalent functionality?

Regards,

Ryan

[igorastakhov]

Ryan,
there is a more general function available in ippSP domain - ippsFIR.
Several steps are required for full substitution of SR ResamplePolyphase:
1) Generate filter coefficients using Mathlab or ippsFIRGen functionality. ippsFIRGen works with the next smoothing windows: ippWinBartlett,ippWinBlackman,ippWinHamming,ippWinHann,ippWinRect while ResamplePolyphase uses Kaiser window - but I think it is not of principle.
2) Use the next function(s) for Multi-Rate filter initialization:ippsFIRMRInitAlloc or a pair of ippsFIRMRGetSize and ippsFIRMRInit (the first one allocates memory buffers internaly, the second provides opportunity to use an external memory buffer allocated by you)
3) Use ippsFIR function for filtering with resampling. MR version supports any arbitrary resampling ratios and initial phases for input/output.

Regards,
Igor

[Chao_Y_Intel]

Ryan,

Igor provided some recommendation of the replacement. Besides, the SR domain function will continue to be supported in the IPP 6.1 product. You can use the SR functions in IPP 6.1 release. We are working on the KB articles, which will help the users.

Thanks,
Chao

[PaulF_IntelCorp]

Hello Aaron,

As you know, the library is quite large (>12,000 functions). The maintenance and testing associated with this very large number of functions is quite significant. With the introduction of the Intel AVX instruction set (Sandy Bridge microarchitecture processors) the process of moving functions forward to support these new instructions simply adds to that load.

Paul

[jmason]

I went through the same song and dance Aaron did only to find in the 7.0 release notes where it mentions ippSR being dropped. I did read over the release notes before upgrading but not thoroughly enough apparently. This is quite frustrating though as a simple task now requires some refactoring be done. Perhaps for future releases, Intel could have those aforementioned KB articles prepared so we developers(customers) don't have to search so hard to find the new/different functions to complete a specific task.

Justin

[shyaki]

I am very mad at Intel about this. I had to re-code our audio re-sampling engine and it is still not working properly. I would like to propose to put back SR lib in 7.0.2.

[rmitchle]

I've got back to looking at this problem.

ippsFIRMR does NOT support arbitrary resampling ratios; it requires *integer* up- and downsampling factors. ippsResamplePolyphase allowed any (real-valued) ratio, and it could be altered during processing (which is what we need). FIRMRInit requires the up and down ratios to be fixed upon initialisation.

Thus, ippsFIRMR is NOT a general replacement for ippsResamplePolyphase. Not even close.

There is FREE software (libsamplerate) which allows even irrational resampling ratios, alterable on-the-fly. I would use it, but it has GPL licensing issues.

Why did we PAY for the IPP again??

This needs to be looked at ASAP by Intel.

[shyaki]

When I replacedippsResamplePolyphase with ipsFIRMR by sampling the audio on a block-wise manner, I got clicking noise in the resampled signal. This may be due to integer sampling factors.
However, in theory, does ippsResamplePolyphase internallyuse some kind of muti-rate filter too?

[Vladimir_Dudnik]

Hello,

could you please share piece of source code where you use FIRMR functions? The noise might be caused by non optimal use of these functions.

Yes, ippsResamplePolyphase internally use FIR filters.

Vladimir

[shyaki]

What I want to do is to resample signals between 44.1 and 48 Hz. I receiveblocks of audio samples and resample them to the target rate. When I resample the current block, I can keep previous block, but I do not have next block.

//compute the sampling factors

unsigned long ulLCM = _GetLCM(m_ulSrcRate,m_ulDstRate);

m_ulUpFactor = ulLCM / m_ulSrcRate;

m_ulDownFactor = ulLCM / m_ulDstRate;

////----------create the linear filter ------------

m_ulFilterLen = 2*m_ulUpFactor - 1 ;

m_pFilterTaps = (Ipp32f*)_aligned_malloc(sizeof(Ipp32f)*m_ulFilterLen,16);

unsigned long N = m_ulFilterLen / 2 + 1;

ippsVectorRamp_32f(m_pFilterTaps,N,1.0/N,1.0/N);

ippsVectorRamp_32f(m_pFilterTaps+N-1,N,1.0,-1.0/N);

//set up the delay line for each track;

m_ulDelayLen = (m_ulFilterLen + m_ulUpFactor - 1)/m_ulUpFactor;

for (i=0; i

{

Ipp16s* pDelayLine = (Ipp16s*)_aligned_malloc(sizeof(Ipp16s)*m_ulDelayLen,16);

ZeroMemory(pDelayLine,sizeof(Ipp16s)*m_ulDelayLen);

m_apDelayLine = pDelayLine;

}




////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

HRESULT CFIRMultiRateResampler::Resample16BitMonoTo16BitMono2(unsigned long in_ulNbSourceBuffer, void * in_pvSourceBuffer16Mono, unsigned long & out_ulNbDestinationBuffer, void * in_pvDestinationBuffer16Mono, EMvAudioResamplerMode in_eAudioResamplerMode, unsigned long in_ulAudioTrack)

{

HRESULT hr = MV_NOERROR;

unsigned long i;

IppStatus st = ippStsNoErr;

Ipp16s *pSrc = (Ipp16s*)in_pvSourceBuffer16Mono; //pointer to the current src sample buffer

Ipp16s *pDst = (Ipp16s*)in_pvDestinationBuffer16Mono; //pointer to the current dst sample buffer

unsigned long ulDstSamples = 0; //number of dst samples we generate by resampling

int numIters = 1; //iter. count

Ipp16s *pDelayLine = m_apDelayLine[in_ulAudioTrack]; //delay line

double dPhase = m_dPhase[in_ulAudioTrack];

if (in_ulAudioTrack >= m_ulNbAudioTracks)

{

assert(!"CFIRMultiRateResampler::Resample16BitMonoTo16BitMono - invalid audio track index!");

return MV_E_OUT_OF_RANGE;

}

//extend to the delay line if seek

if ( in_eAudioResamplerMode == keMvAudioResamplerModeSeek )

{

ippsSet_16s( *pSrc, pDelayLine, m_ulDelayLen);

dPhase = m_ulFilterLen/2+1;

}

//divide source to two parts

unsigned long ulSrcSamples = (in_ulNbSourceBuffer / m_ulDownFactor)*m_ulDownFactor; //part1

unsigned long ulWorkSamples = in_ulNbSourceBuffer - ulSrcSamples; //part2

//---------re-sample part1---------------

ulDstSamples = ulSrcSamples*m_ulUpFactor/m_ulDownFactor;

if (ulDstSamples > out_ulNbDestinationBuffer)

{

hr = MV_E_DESTINATION_BUFFER_TOO_SMALL;

assert(SUCCEEDED(hr));

return hr;

}

numIters = ulSrcSamples / m_ulDownFactor;

st = ippsFIRMR32f_Direct_16s_Sfs(pSrc,pDst,numIters,m_pFilterTaps,m_ulFilterLen,m_ulUpFactor,1,m_ulDownFactor,0,pDelayLine,0);

assert(st == ippStsNoErr);

pSrc += ulSrcSamples;

pDst += ulDstSamples;

dPhase += ulSrcSamples;

////debug

//memcpy(pDst,pSrc,ulWorkSamples*sizeof(Ipp16s));

//ulDstSamples+=ulWorkSamples;

//ulWorkSamples = 0;

//---------re-sample part2--------------

if (ulWorkSamples > 0)

{

//update the delay line

for (i = 0; i

{

pDelayLine = *(pSrc- i - 1);

}

//copy part2 to the work buffer

Ipp16s *pWorkBuffer = m_apWorkBuffer[in_ulAudioTrack];

memcpy(pWorkBuffer,pSrc,ulWorkSamples*sizeof(Ipp16s));

pSrc += ulWorkSamples;

//update the delay line

for (i=0; i

{

pDelayLine = *(pSrc - i + 1);

}

//extend to max

for (i=0; i

{

pWorkBuffer[ulWorkSamples+i] = pWorkBuffer[ulWorkSamples-1];

}

//re-sample the work buffer

unsigned long ulResampledSamples = ulWorkSamples*m_ulUpFactor / m_ulDownFactor;

int numIters = m_ulWorkMaxSamples / m_ulDownFactor;

IppStatus st = ippStsNoErr;

//update the dst samples count

ulDstSamples += ulResampledSamples;

if (ulDstSamples > out_ulNbDestinationBuffer)

{

hr = MV_E_DESTINATION_BUFFER_TOO_SMALL;

assert(SUCCEEDED(hr));

return hr;

}

st = ippsFIRMR32f_Direct_16s_Sfs(pWorkBuffer,pDst,numIters,m_pFilterTaps,m_ulFilterLen,m_ulUpFactor,1,m_ulDownFactor,0,pDelayLine,0);

assert(st == ippStsNoErr);

dPhase += ulDstSamples;

}

//num. of the result samples

out_ulNbDestinationBuffer = ulDstSamples;

m_dPhase[in_ulAudioTrack] = dPhase;

return hr;

}

[shyaki]

Hello, Vladimir

Could you please take a look at my code? I am not sure about the following:

My code is based on the sample code from the IPP book. Is the linear filter not good? I divide the input buffer to two parts to try to handle the boundary. Is it correct? Should I use ippsFIRMRStreamInitAlloc to handle the transition between buffers? Many thanks in advance.

[Arto_Lehdonm__228_ki]

Quoting igorastakhov

Ryan,
there is a more general function available in ippSP domain - ippsFIR.
Several steps are required for full substitution of SR ResamplePolyphase:
1) Generate filter coefficients using Mathlab or ippsFIRGen functionality. ippsFIRGen works with the next smoothing windows: ippWinBartlett,ippWinBlackman,ippWinHamming,ippWinHann,ippWinRect while ResamplePolyphase uses Kaiser window - but I think it is not of principle.
2) Use the next function(s) for Multi-Rate filter initialization:ippsFIRMRInitAlloc or a pair of ippsFIRMRGetSize and ippsFIRMRInit (the first one allocates memory buffers internaly, the second provides opportunity to use an external memory buffer allocated by you)
3) Use ippsFIR function for filtering with resampling. MR version supports any arbitrary resampling ratios and initial phases for input/output.

Regards,
Igor

Igor,

Could you provide some details about generating the filter coefficients?

In our case, we're resampling from 44.1 kHz to 8 kHz. As I understand, this will require an upsampling factor of 80 and a downsampling factor of 441. Should we now generate the filter coefficients (using ippFIRGen) with 44.1 kHz * 80 as the sample rate? And how should one determine the filter length?

In this case, the normalized filter cutoff frequency (4 kHz / (44.1 kHz * 80)) is very small and it seems to be difficult to get the pass band amplitude response to be flat.

Also, I assume the filter coefficients need to be scaled according to the upsampling factor?

All in all, I also wish the original polyphase resampling function was available (or something equivalent for straightforward resampling).

Regards,

Arto

[lincbrookes]

I'm also upset that this functionality was removed from IPP 7 - without warning. I always wondered why this very useful function was hidden in the Speech Coding section, rather than in the general audio coding section. At any rate, here is a simple solution to the problem: link with the old version of the static speech coding library - which seems to not conflict with the new libraries. To wit:

// include this code before your calls to ippsResamplePolyphase...
// thisworks is for Visual C 10 and Ipp 5

#if (IPP_VERSION_MAJOR >= 7)

extern "C" {

// from ippsr.h

struct ResamplingPolyphaseFixed_16s;

typedef struct ResamplingPolyphaseFixed_16s IppsResamplingPolyphaseFixed_16s;

IppStatus __STDCALL w7_ippsResamplePolyphaseFixed_16s(const IppsResamplingPolyphaseFixed_16s *pState,

const Ipp16s *pSrc, int len, Ipp16s *pDst,

Ipp32f norm, Ipp64f *pTime, int *pOutlen);

IppStatus __STDCALL w7_ippsResamplePolyphaseFixedFree_16s(IppsResamplingPolyphaseFixed_16s* pSpec);

IppStatus __STDCALL w7_ippsResamplePolyphaseFixedInitAlloc_16s(IppsResamplingPolyphaseFixed_16s** pState, int inRate, int outRate, int len, Ipp32f rollf, Ipp32f alpha, IppHintAlgorithm hint);

}

#define ippsResamplePolyphaseFixed_16s w7_ippsResamplePolyphaseFixed_16s

#define ippsResamplePolyphaseFixedFree_16s w7_ippsResamplePolyphaseFixedFree_16s

#define ippsResamplePolyphaseFixedInitAlloc_16s w7_ippsResamplePolyphaseFixedInitAlloc_16s

// use the location of your old ippstatic libs in the following pragma
#pragma comment(lib, "c:/SDK/IPP/5.0/ia32/lib/ippsrmerged.lib")
#endif

How to do this for other CPU types is left as an exercise to the reader.
Linc

[thomtek]

Here's another vote that removal of theSR non-integer (AKA arbitrary ratio) resampling functions is a big disappointment. We use them in several key portions of our analysisSW. Recoding this functionality is a serious waste of time for us to get back to previous working v6 behavior.

Wewere waiting for7.0.2 which contains fixes to 2 bugs we submitted, but now cannot due to this loss of functionality, until we recreate the resampling functions and test them. And as Ryan has noted, the FirMR functions do not provide the functionality needed for "true" arbitrary ratio resampling. This requires a significant amount of work to implement and verify.

These are very basic and useful DSP functions. They certainly are not specific to SR work, as our use is proof of. Why can they not be migrated to the Filtering Functions portion of IPP?

Tom

[hill_matthew]

I wanted to add my voice to the chorus saying that I find the removal of these functions extremely disappointing. I use them in a pro-audio application and their removal means I need to rely on hacks to get IPPv6 running alongside v7 (frankly it just feels dangerous since I don't know the internal workings) or I need to stick with IPPv6 to take the low-risk option. Until there is an absolute need for me to upgrade to IPPv7 (which I otherwise would have been happy to do) I will be sticking with IPPv6 since I don't have the resources to test against multiple architectures as would ne needed if I went with Linc's suggestion.

Having a fast and cross-platform resampler that is commercially viable for not being encumbered with the GPL was 50% of the reason for my investment in IPP (having a blazing fast FFT was the other).

I may consider using the Speex resampler as that is released under a license similar to BSD.

[Ying_S_Intel]

Dear Customers,

Thanks for your concern and feedback on this issue. Currently we are reviewing the alternative possible solutions to address this issue in IPP 7.0, and we will keep you posted soon.

Ying

[Ockham_s_Razor]

Adding my vote to restore. I produce both freeware and commerical products using IPP, it relies upon the resampling abilities. Why remove what is a basic idea only to have to replace it with a bunch of code that requires lots of work to define the propery parameters and in many cases are SLOWER.

As Turing showed decades ago, as long as you can loop and count you can do every computation, given enough time and memory. So the logic that there is an alternative way just doesn't always provide a viaable solution.

I use a software pattern called flyweight that makes multiple resamplers with little overhead. Now I would have to rewrite all this code to contend with the different filters created.

As the issue with testing, that is bull.Just don't convert it for the newer systems.A tweek here or there and all the tests run. Really disapointed in this decision

[David_Hamilton]

Another vote to please bring it back! As has been said already it would fit nicely into other libraries as a generic resampling function. It is the one thing we use from the Speech Recognition library. My particular application involves resampling audio to and from a number of different sample rates in real time and we are faced with a bunch of work to reimplement or find another library.