I'm trying to use 'ippsResamplePolyphaseFixed' based on the sample code I found here. Most makes sense and I have things almost working. The problem I have (in addition to the outdated API being used in the sample code) is that I am working on sample frames processed in real time as opposed to file I/O. That is, I am not reading a chunk from a file and resampling, I am reading a smaller chunk from a media stream (i.e. roughly 60 msec at 11kHz) and converting to an even smaller chunk (8kHz). The example code uses a base buffer size of 4096 samples and a history of 128 samples . . .
Where do these values come from? If I am providing input chunks of 660 samples should the buffsize / history values change or do I need to fill the buffer with more samples before trying to extract the converted samples? The end result of my current implementation is that about 90% of the chunk is converted properly but I am seeing about 10% of trailing silence in the output for each 60 msec chunk.
this functionality doesn't support separate delay line as, for example, FIRMR functions - so there is detailed description in the manual how to provide right conditions for correct function work:"Input vector with indices less thanpTimecontains the history data of filters. The history length is equal toflen/2 forippsResamplePolyphaseFixedfunction , and [1/2window*max(1, 1/factor)]+1 forippsResamplePolyphasefunction. Hereflenis the filter length andwindowis the size of the ideal lowpass filter window. The input vector must contain the same number of elements with indices greater thanpTime +lenfor the right filter wing for the last element."
input block size of 4096 is just for example - you can use any other, history == 128 - also an example parameter - you can use any other that corresponds to you filter length (number of coefficients). Also yo can try FIRMR (ippsFIRMRGetSize/Init and then ippsFIR) that supports explicit delay line - it will be easier for you to have stitched output signal.