ippsResamplePolyphase

ippsResamplePolyphase

HiippsResamplePolyphase_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

56 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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

Hi VladimirI 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

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

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

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

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

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

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.

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.

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?

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

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[i] = 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[i] = *(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[i] = *(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;

}

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.

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

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

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

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.

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

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

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.

Wow! Intel removed Speech Rec, but continues to advertise it as a feature of the 7.0 product!

Click on the DETAILS tab on this page:
http://software.intel.com/en-us/articles/intel-ipp/

I also use the polyphase resampling functions and won't be able to switch to 7.0. I sure hope the quality of the coding in IPP is better than this poor product management.

Thank you for noting that mistake. It will be corrected.

You should also remove it from the "Click to Enlarge" graphic on that same page.

Thank you, I've also requested that the graphic be updated.

Ying,

Please update us on whether ippResamplePolyphase will be restored to the IPP lib. We need to keep up with the newest versions of IPP to support new processors,but cannot without the function being restored or brewing our own. Creating our own version will require a significant effort for us since its used in multiple places in our design and is tightly tied in. We need to know if we shouldgo ahead with creating our own or not.

If it will be restored, please let us know when that release is anticipated.

Thank you,
Tom

Hello, anyone??

Can someone PLEASE respond with the status of this issue ASAP?
We need to know whether we need to replicate the functionality if it will not be restored, so we can move to v7.

Tom

We are working on it and hope to have a download of the ippsResamplePolyphasefunction for Intel IPP 7.0 for customers who request it in a few weeks. Thanks for your patience.

Technical Consulting Engineer
Intel Corporation

It's been a few weeks. How do I request it?

Yes, we would also like to request the download. Please let us know how to do so.

Tom

Is there an update on the availability of the ippsResamplePolyphase function with the new libraries?Thanks.

We are now releasing the C source code for the most frequently requested Intel IPP Speech Recognition function, ippsResamplePolyphase, in the hope that it will enable you to continue to provide outstanding application performance without losing key speech recognition functionality. This release falls under the Intel IPP EULA (see EULA here http://software.intel.com/en-us/articles/intel-integrated-performance-pr...).

The link to the ippsResamplePolyphase source code download is here

http://registrationcenter.intel.com/irc_nas/2223/ipp-resample-07-21-2011...

Technical Consulting Engineer
Intel Corporation

Thanks for providing the source code. Apart from being a fascinating look into what is likely the actual original Intel C implementation of the functions, it does allow people to get on. However, the delivery falls severely short on two related accounts:

  • Performance (i.e. "..continue to provide outstanding application performance..") - because it is C-only without use of other IPP routines (except mallocs). I must admit I only cast a quick glance but I did not find any other IPP functions in use. I would expect this to perform much worse than the best IPP 6.1 optimizations (on a relevant CPU).
  • Re-implementation of the functions using the new added functionality i.e. the new interfaces (to the degree possible - I have not analyzed the different earlier comments on this in detail), which I would think should provide excellent performance (at least much better) and also provide a way forward for people that may want to (now or later) change to the new interfaces.

I was expecting a solution that either restored the original functionality completely (with full performance) as part of IPP or a solution that provided a path that would use the new interfaces but be backwards compatible at comparable performance. Maybe I misunderstood the intentions - am I the only one that was expecting something else (as outlined above) instead of the C source code provided now...?

- Jay

I looked over the new code and was also surprised that it was essentially plain C-code, with no optimized IPP sub-functions used in the core resampling calculation routines. It makes me worried that as is, it will be much slower than thev6 routines (and the "arbitrary" ratio resampling was already fairly slow then).

Question for Intel IPP folks: Is this C code the actual code that was compiled to create the original optimized IPP SR resampling functinons, or is this a C code "interpretation" of the orignal optimized code (previously in asm or ???)?

If its the latter, then I expect it to cause a significant loss of performance if we just compile it into our own systems. In fairness, I've not had a chance yet to benchmark it against thev6.0functions.

I too was expecting it to be (re)integrated with IPP 7.0.I take this to mean this the last support we'll get for these functions and they will not be added back into IPP. Please correct me if this is wrong.

I fully agree. I have also not compared the performance of the plain C variant against those from IPP v. 6.x but I doubt that they will perform as good as those, because I suppose that Intel actually did some hand-optimization of the functions for the various CPU instruction sets. I would expect that given C code is similar to the plain PX variant of the IPP v. 6.x unless you specifically allow your compiler to optimize for specific platforms or even just generally (that admittedly would be the normal case).

Why not simply restore these functions fully into IPP 7.0 reusing the optimized code from IPP v. 6.1 with no new optimizations added (for now). We are thus asking for a restoration of just these resampling functions - not the entire Speech Recognition domain. You could move the rstored functions to the general audio processing domain.

I sincerely hope that Intel will listen to their ISV customers on this issue. It is far easier and less expensive for their ISV customers to have Intel do the job once, and not put a strain on everyone using these functions.

A different approach could be to have add further new functions/interfaces that would actually allow a full replacement of these functions because as I understand earlier comments, this is not the case now (i.e. that the new functions currently available in IPP 7.0 can not fully replace the old functions). This still requires a cumbersome handling by all ISVs but it would allow an actual replacement, which is otherwise not the case now (and in this case you could provide some sample source code on how to do the replacement). Some times things have to go (not these functions!) and I can appreciate that but there should always be some sort of replacement allow similar functionality to be implemented.

- Jay

Hi everyone,has anyone actually done a performance-comparison of the old V6 functionalitywith the source-code that Intel has provided some time ago?We have just recently jumped on the IPP waggon to implement some high-performance DSP-functionality.I'm also looking for some high-performance-code to do "clock-skew-compensation",where I want to adapt sample-rates which deviate less than 0.01% in real-life.Currently I use the secret-rabbit-code, but I really look for something that createsless computational load while still being good quality...So if there is a substancial performance-delta between the V6 functionality & theplain-vanillascalar code that Intel recently provided, I would also give my voteto reintroducethose functions (both the _16s and the _32f) in an update of V7...Best regards,Tobias

I'd also like to register my underwhelm at the problems this change has caused.I've recently taken over a bunch of audio DSP contractor-written code written against IPP 6. None of this code is for speech recognition. Like most people, I've got more important things to work on than fixing tool chain regresssions.Has anyone had success linking against and IPP 7 and the ippsr portions of IPP 6.1? This strategy doesn't fill me with confidence as lots of things could go wrong at the linker level without much visbility of the problems. I also suspect it might get increasingly difficult with future versions of IPP.A previous post said that linking against the older ippsr libraries in addition to IPP 6.1 will still be quite optimal as much of the work is delegated to other functions in ipp. This doesn't seem to be the case with the C replacement code whichonly delegates to ipps in a handful of calls in 2000+ lines of code. Do these calls really account for the majority of execution time? It would be good to have a statement from Intel on this as they have detailed knowledge of the implementation: Is it likely to be more optimal attempting to link IPP 6.1 sr and IPP 7.0 rather than using the C replacement?

One more vote to return backippsResamplePolyphase.

In the very latest IPP 7.0 build I can see the following function. Is that newly added in the latest IPP? Can someone with more DSP knowledge than me explain the difference between this function andippsResamplePolyphaseFixed in a nutshell.ippsResamplePolyphase_AMRWBE_16sHaving problems getting that C code to build to unresolved externals for dependencies on the following. Probably something stupid that I'm doing. Is it meant to be possible to include ippsr.h in the source archive and then link that to an IPP 7 app without other changes?_ippsDeinterleave_32f@16_ippsInterleave_32f@16

Walter,

Can you, or someone at Intel PLEASE post a definite Yes or No whether the ResamplePolyphase functions will be added back into IPP in the future? This has really dragged out a long time.

If the answer is No, then I would really hope to seea Knowledge Base article written to help those of us who want to try linking the v6.1 SR lib with v7.0 IPP. I've seen this mentioned, but don't know how to go about doing it or what the implications are AFA handling new CPUs, etc.

Thanks,
Tom

Quoting Walter Shands (Intel)

We are now releasing the C source code for the most frequently requested Intel IPP Speech Recognition function, ippsResamplePolyphase, in the hope that it will enable you to continue to provide outstanding application performance without losing key speech recognition functionality. This release falls under the Intel IPP EULA (see EULA here http://software.intel.com/en-us/articles/intel-integrated-performance-pr...).

The link to the ippsResamplePolyphase source code download is here

http://registrationcenter.intel.com/irc_nas/2223/ipp-resample-07-21-2011...

Quoting Walter Shands (Intel)

We are now releasing the C source code for the most frequently requested Intel IPP Speech Recognition function, ippsResamplePolyphase, in the hope that it will enable you to continue to provide outstanding application performance without losing key speech recognition functionality. This release falls under the Intel IPP EULA (see EULA here http://software.intel.com/en-us/articles/intel-integrated-performance-pr...).

The link to the ippsResamplePolyphase source code download is here

http://registrationcenter.intel.com/irc_nas/2223/ipp-resample-07-21-2011...

Quoting Walter Shands (Intel)

We are now releasing the C source code for the most frequently requested Intel IPP Speech Recognition function, ippsResamplePolyphase, in the hope that it will enable you to continue to provide outstanding application performance without losing key speech recognition functionality. This release falls under the Intel IPP EULA (see EULA here http://software.intel.com/en-us/articles/intel-integrated-performance-pr...).

The link to the ippsResamplePolyphase source code download is here

http://registrationcenter.intel.com/irc_nas/2223/ipp-resample-07-21-2011...

Quoting Walter Shands (Intel)

We are now releasing the C source code for the most frequently requested Intel IPP Speech Recognition function, ippsResamplePolyphase, in the hope that it will enable you to continue to provide outstanding application performance without losing key speech recognition functionality. This release falls under the Intel IPP EULA (see EULA here http://software.intel.com/en-us/articles/intel-integrated-performance-pr...).

The link to the ippsResamplePolyphase source code download is here

http://registrationcenter.intel.com/irc_nas/2223/ipp-resample-07-21-2011...

Quoting Walter Shands (Intel)

We are now releasing the C source code for the most frequently requested Intel IPP Speech Recognition function, ippsResamplePolyphase, in the hope that it will enable you to continue to provide outstanding application performance without losing key speech recognition functionality. This release falls under the Intel IPP EULA (see EULA here http://software.intel.com/en-us/articles/intel-integrated-performance-pr...).

The link to the ippsResamplePolyphase source code download is here

http://registrationcenter.intel.com/irc_nas/2223/ipp-resample-07-21-2011...

Quoting Walter Shands (Intel)

We are now releasing the C source code for the most frequently requested Intel IPP Speech Recognition function, ippsResamplePolyphase, in the hope that it will enable you to continue to provide outstanding application performance without losing key speech recognition functionality. This release falls under the Intel IPP EULA (see EULA here http://software.intel.com/en-us/articles/intel-integrated-performance-pr...).

The link to the ippsResamplePolyphase source code download is here

http://registrationcenter.intel.com/irc_nas/2223/ipp-resample-07-21-2011...

Quoting Walter Shands (Intel)

We are now releasing the C source code for the most frequently requested Intel IPP Speech Recognition function, ippsResamplePolyphase, in the hope that it will enable you to continue to provide outstanding application performance without losing key speech recognition functionality. This release falls under the Intel IPP EULA (see EULA here http://software.intel.com/en-us/articles/intel-integrated-performance-pr...).

The link to the ippsResamplePolyphase source code download is here

http://registrationcenter.intel.com/irc_nas/2223/ipp-resample-07-21-2011...

The provided download link doesn't seem to to valid. How do I obtain the C code listed above?

Walter,

How can I get the files listed in the link? I'm unable to download the file 'ipp-resample-07-21-2011.zip' using the provided link.

Thanks,
Ryan

I finally got around to doinga comparison of the origianl v6 IPP resampler vs the C replacement code released by Intel. I tested only the 32f version as that is all we use. YMMV on the 16-bit stuff.

I switched between the v6 IPP functions, and C code compiledwith VS2010 using standard "Release" optimizations.I had it (separately) upsample and downsample a large data record andmeasured elapsed time.

On a 32-bit WinXP system (Xeon), the C-version was 2-3 times FASTER than the IPP version. Yes, FASTER! It appears the IPP version may have been built without optimizations, but that is just a guess.

On x64/Win7 systems (Celeron and I7), the C and IPP versions were approx the same speed. At least the C version was not significantly slower.

Comparison of output data showed IPP and C produced identical results. So it appears the C code is the actual implementation used byIPP.

HTH others who are trying to decide whether to use it.

Quoting p27838Walter,

How can I get the files listed in the link? I'm unable to download the file 'ipp-resample-07-21-2011.zip' using the provided link.

Thanks,
Ryan

Hi,

Please download 'ipp-resample-07-21-2011.zip from this link, its working now.

http://registrationcenter.intel.com/irc_nas/2223/ipp-resample-07-21-2011.zip

Thanks,

Naveen Gv

Hi Naveen (or anyone else from Intel),

I've downloaded the above zip file but it seems to be corrupt when you try and extract the files (I got someone to confirm it didn't work for them either)

Could you please check this link and update it with a working copy?

Thanks a lot!

Jason

Hi Everyone !

Can not extract files too, they seem to be decrypted.

Will be glad to get password or any assistance.

Thank a lot !
Svetlana

Svetlana,

The password is resample (without the quotes)

Regards,
Igor

Quoting thomtekWalter,

Can you, or someone at Intel PLEASE post a definite Yes or No whether the ResamplePolyphase functions will be added back into IPP in the future? This has really dragged out a long time.

If the answer is No, then I would really hope to seea Knowledge Base article written to help those of us who want to try linking the v6.1 SR lib with v7.0 IPP. I've seen this mentioned, but don't know how to go about doing it or what the implications are AFA handling new CPUs, etc.

Thanks,
Tom

Thanks for your patience, after reviewing our customer feedback, we have reached the following approach:

1. The ippsResamplePolyphase will be likely considered by product planning for future releases. There is no timeline to confirm at this time, we will keep you updated once it becomes available. You can also use this DPD200267116 for your reference. For now please use this KB for alternative solution in IPP 7.0.

2. The other speech recognition functions are under review for the future release. Those who need these APIs from speech recognition should continue to use 6.1. We would like to learn your feedback on this.

Again, thanks for using Intel IPP.

Sincerely,
Intel IPP Team

Hi Chao,

That sounds like a very good approach! Please consider carrying out 1) and adding it back to the product as soon as possible. It seems that the released souce code could be used immediately and with the proper compilation options, it would even perform comparably. We have no demand that the resurrection of these resampling functions are hand-tuned.

Re 2) I have no comments as we do not use any of the functions in that domain. My only plea would be that the considerations around these functions do not influence the time frame of carrying out 1) for restoring the resample functions.

Thank you very much for listening to your customers.

Best regards,

- Jay

Chao,
I have been following this issue for a year after submitting a ticket to you
guys when 7.0 was released. As before, I am dismayed that you guys
removed these functions in the first place. Not having them forced us to
stick with 6.1.

I definitely hope that your planners put Polyphase resampling back in IPP
ASAP. We depend on IPP. It is a great product and I hope that it continues to be.

(I noticed that Intel holds a patent related to Polyphase resampling... can you
guys come clean and admit that IP is the real issue on why Polyphase resampling is not in the library?)

Best,
Dal

In two posts #2and #6at the beginning of the thread developers expressed concerns regarding removing
some IPP domains, renaming and changing arguments of IPP functions.

I have the same concerns and Isupport that point of view for 100%.

Regarding a maintenance of a set of~12,000 functions in IPP.

Unfortunately,IPP is not atemplate-based from the beginning, or after versions 4 or 5. Even if there is a
template based extensionI consider a C-style approach in implementing IPP functionsas a significant design
flaw of the library. You didn't use OOP ( Objects Oriented Programming ) approach.

Note: Refactoring of an IPP functionis a good thing if it is done inside of IPP and doesn't affect developers
and customers. All cases whenyou change a name or arguments list of a functionshould be avoided.

Best regards,
Sergey

Pages

Leave a Comment

Please sign in to add a comment. Not a member? Join today