- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Can someone please tell me what the practical difference is between defining a multirate filter using ippsFIRMRStreamInitAlloc vs ippsFIRMRInitAlloc?
The documentation in the FIR part of the IPPS manual (version 6) is not helpful with this.
I have tired filtering some test data with both of these and they produce the same output. The "stream" in the first one's name suggests that it might be suitable for "streaming" applications where you want to call the filter lots of times and have the result "stream" of data be the concatenation of all the blocks from the input "stream". However, this implies that there is some sort of memory of the state of the filter from the last call. I tried filtering some data, then filtering all zeros, and the output of the second call was all zeros, so there is no memory.
What I want to do is to change the sampling rate on a huge file of data. The file is so big that it has to be broken up into chunks. However because of the impulse response of the filter output lags the input by about NTAPS/2, so you have to overlap the blocks to make sure the samples at the end of a block are handled correctly and not lost. It seems like there should be a way to do this without having to overlap chunks of data. Perhaps this is what the "delay line" settings are for, but the IPPS manual really says nothing about what the delay lines are for, so it is hard to know. There is no concept of "delay line" in the Multirate DSP book I'm referencing (Crochiere & Rabiner), so I have not been able to translate the terminology.
Clarification of the difference between "stream" and "non-stream" filters and suggestions for a simple way to process my file would be much appreciated.
Cheers,
Randall.
Can someone please tell me what the practical difference is between defining a multirate filter using ippsFIRMRStreamInitAlloc vs ippsFIRMRInitAlloc?
The documentation in the FIR part of the IPPS manual (version 6) is not helpful with this.
I have tired filtering some test data with both of these and they produce the same output. The "stream" in the first one's name suggests that it might be suitable for "streaming" applications where you want to call the filter lots of times and have the result "stream" of data be the concatenation of all the blocks from the input "stream". However, this implies that there is some sort of memory of the state of the filter from the last call. I tried filtering some data, then filtering all zeros, and the output of the second call was all zeros, so there is no memory.
What I want to do is to change the sampling rate on a huge file of data. The file is so big that it has to be broken up into chunks. However because of the impulse response of the filter output lags the input by about NTAPS/2, so you have to overlap the blocks to make sure the samples at the end of a block are handled correctly and not lost. It seems like there should be a way to do this without having to overlap chunks of data. Perhaps this is what the "delay line" settings are for, but the IPPS manual really says nothing about what the delay lines are for, so it is hard to know. There is no concept of "delay line" in the Multirate DSP book I'm referencing (Crochiere & Rabiner), so I have not been able to translate the terminology.
Clarification of the difference between "stream" and "non-stream" filters and suggestions for a simple way to process my file would be much appreciated.
Cheers,
Randall.
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Randall,
Don't use FIR function with "Stream" suffix - the only difference it has in comparison with the general purpose MR FIR - it uses data before pSrc as delay line - it will not be supported in the next IPP version and has limited optimization only (for 1specific case).
You should use ippsFIRMRInitAlloc/ippsFIR functionality in order to process long vectors by chunks - stitching mechanism is provided automatically with delay line support - you don't need to shift pSrc pointer to overlap the blocks. Pay attention to thenumIters parameter only as it is a number of iterations, not the source or destination length.
Igor
Don't use FIR function with "Stream" suffix - the only difference it has in comparison with the general purpose MR FIR - it uses data before pSrc as delay line - it will not be supported in the next IPP version and has limited optimization only (for 1specific case).
You should use ippsFIRMRInitAlloc/ippsFIR functionality in order to process long vectors by chunks - stitching mechanism is provided automatically with delay line support - you don't need to shift pSrc pointer to overlap the blocks. Pay attention to thenumIters parameter only as it is a number of iterations, not the source or destination length.
Igor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Igor,
Thanks for your reply. I still don't understand what the delay lines actually are or when/how you use them. If you could sketch out for me the high level steps to decimate the samples in a large file by a rate of 24/25, then I would very much appreciate it. I'll attach my little test program so that you can see what I'm currently doing (or trying to do).
Cheers,
Randall.
Thanks for your reply. I still don't understand what the delay lines actually are or when/how you use them. If you could sketch out for me the high level steps to decimate the samples in a large file by a rate of 24/25, then I would very much appreciate it. I'll attach my little test program so that you can see what I'm currently doing (or trying to do).
Cheers,
Randall.
[cpp]/* test multirate FIR filter functions in the IPP library. */ #include#include #include #include #include #define DSIZE 1000 #define NCHUNKS 10 #define FIR_MR_UP 24 // multirate sample rate increase factor #define FIR_MR_DOWN 25 // multirate sample rate decrease factor #define FILTER_TAPS 12 // number of conceptual taps in lowpass filter #define NTAPS (FILTER_TAPS*FIR_MR_UP) // number of taps in actual low-pass filter. // this is oversampled by a factor of FIR_MR_UP by design int main(int argc, char *argv[]) { Ipp64f taps64[NTAPS]; Ipp32f taps32[NTAPS],taps_check[NTAPS]; Ipp32f *indata,*outdata; int i,chunk,status; IppsFIRState_32f *fState=NULL; FILE *fp=NULL; char *infilename = "/tmp/mr_FIR_in",*outfilename; indata = ippsMalloc_32f(DSIZE); outdata = ippsMalloc_32f(DSIZE); memset(outdata,'',sizeof(float)*DSIZE); for(i=0; i = drand48()-0.5 + sin(0.1*i*M_PI)*0.1; indata[0] = 1.0; // dump test input data if ((fp = fopen(infilename,"w")) ==NULL) { fprintf(stderr,"Cannot open test data file %sn",infilename); return 1; } fwrite(indata,sizeof(float),DSIZE,fp); if(fp !=NULL) { fclose(fp); fp=NULL; } // get filter taps // the cutoff freq for the lowpass filter in a multirate system must be the minimum of the cutoff // freqs for the two conceptual filters that would be required after the up and down sampling. In // practise, this means the min of 1/FIR_MR_UP and 1/FIR_MR_DOWN. See Crochiere & Rabiner eq 2.84. // the IPP filters are normalised so that the max freq is 0.5, so the cutoff must be relative to 0.5 status = ippsFIRGenLowpass_64f(0.5/FIR_MR_DOWN, taps64, NTAPS, ippWinHann, ippTrue); if(status != ippStsNoErr) { printf("ippsFIRGenLowpass_64f returned %dn",status); return status; } // copy taps and normalise. For a multirate filter, the normalisation is the rate upscale factor for (i=0; i = taps64*FIR_MR_UP; // create multirate filter status = ippsFIRMRInitAlloc_32f(&fState, taps32, NTAPS, FIR_MR_UP, 0, FIR_MR_DOWN, 0, NULL); if(status != ippStsNoErr || fState==NULL) { printf("ippsFIRMRInitAlloc_32f returned %dn",status); return status; } // check taps - verification only for(i=0; i =0.0; status = ippsFIRGetTaps_32f(fState, taps_check); for (i=0; i ); } // open output file outfilename = "/tmp/mr_FIR_out_chunks"; if ((fp = fopen(outfilename,"w")) ==NULL) { fprintf(stderr,"Cannot open output file %sn",outfilename); return 1; } for (chunk=0; chunk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page