Info on Altivec convolution function (conv) in vDSP.h

[Eric Raas]

Anyone have experience using the 'conv' function described in vDSP.h? I
can sort of get it to work, but can't figure out how the output is
aligned in the result array (or be sure how it should be aligned in the
input arrays - is there FFT style swapping of segments?). I get a
convolved signal out but I seem to lose more at the ends than I'd expect.

An excerpt from vDSP.h is given below. The vDSP pdf guide gives almost
no information on how to use this function. Any insights on arrangement
of data in input and output arrays would be hugely appreciated...

ER




/*
?????????????????????????????????????????????????? ?????????????????????????????
Function conv
convD

Floating Point Convolution and Correlation in Single and Double
Precision

Criteria to invoke PowerPC vector code:
1. signal and result must have relative alignement.
2. 4 <= lenFilter <= 256
3. lenResult > 36
4. signalStride = 1
5. strideResult = 1

If any of the above criteria are not satisfied, the PowerPC scalar
code
implementation will be used. strideFilter can be positive for
correlation or negative for convolution.
?????????????????????????????????????????????????? ?????????????????????????????
*/
/*
* conv()
*
* Availability:
* Mac OS X: in version 10.0 and later in vecLib.framework
* CarbonLib: not in Carbon, but vecLib is compatible with
Carbon
* Non-Carbon CFM: in vecLib 1.0 and later
*/
extern void
conv(
const float signal[],
SInt32 signalStride,
const float filter[],
SInt32 strideFilter,
float result[],
SInt32 strideResult,
SInt32 lenResult,
SInt32 lenFilter) AVAILABLE_
MAC_OS_X_VERSION_10_0_AND_LATER;

[Eric Raas]

> Anyone have experience using the 'conv' function described in vDSP.h?
> I can sort of get it to work, but can't figure out how the output is
> aligned in the result array (or be sure how it should be aligned in
> the input arrays - is there FFT style swapping of segments?). I get
> a convolved signal out but I seem to lose more at the ends than I'd
> expect.
> ...

Got it - here's what worked in the end:

1) pick a filter length (must be between 4 and 26 floats)
2) pick the length of the convolution result (must be more than 36
floats)
3) the length of the *input* signal must then be at least the sum of
the
lengths of the filter and the output minus one (the ends will not be
valid).

In my case I wanted the output result to be the same length as the input
vector, and to be correctly aligned with the input so I could replace a
signal with a smoothed copy of itself. Zero padding at the beginning
and end of the signal with half the length of the filter at each end (
for a total number of zeros equal to the length of the filter) produced
the desired result. For example:

length of original signal = 64 floats
filter length = 16 floats
desired result length = 64 floats
signal length to pass to conv() = 80 floats (minimum would be 79)

signal is zero padded at each end before passing to conv:

0 0 0 0 0 0 0 0 (64 floats) 0 0 0 0 0 0 0 0

I guess this is a fairly standard arrangement for convolution, but I
wish Apple provided more documentation for these useful functions!

[Eric Raas]

Another weird thing, that is mentioned in the pdf file for conv(), is
that if you want convolution (as opposed to correlation) you must set
filterStride to -1 and pass a pointer to the *last* element in the
filter array.