Hi
I can't offer you a solution to the programming assignment, and in fact there are 2
reasons it might also not become a great general purpose solution. I do however have some
affiliation with the interpolation function field and the particular types mentioned in
this thread. With interest I've looked at the pdf about short FIR filters based on the
well known mathematical/computer graphics interpolators, which far a part came from
mechanical/industrial engineering fields quite a while ago.
I struck me there appears to be no particular reason for wanting any of these well known
interpolation polynomials for audip processing purposes on the the basis of their
mathematical and graphical merits. The interpolation curves (or surfaces in more
dimensions) of these kinds have certain properties, which sets them apart from any
n-degree polynomial that via a number of equations and their solution could be directed to
pass through a number of given data points. For instance, the Bezier curve in it's
quadratic form will pass through the data points at the extremes of it's control polygon
and there are possibilities to match the direction (the first order derivative) of the
curve at one end. You could want to use that, or maybe the generally averaging properties
of a Spline function to do some amount of curve matching with given wave shapes.
However, just putting the curve control points at the samples of an input signal, and
doing nothing but interpreting the interpolating function as a very short FIR function
getting sampled in the target (re-) sample domain, does not mean all too much to me. Also,
I suppose you are aware there is only one "perfect" reconstruction function you can use to
compute the "amplitude value" or what you want to call it, between samples, and that's an
infinite sum of sinc functions, which unfortunately for all of us doesn't have a simple
substitute and diminishes rather slowly, so you need a pretty long, or long delaying,
resample filter to become accurate. Might not be a problem for for instance a gaming
application.
The reason the interface and the implementation of a general resample function might be
not as readily found, and not as trivial as some may want it might be that some issues
aren't easily resolved int he area, even if you've found the type of interpolator you
like. From a physics or signal point of view, you might need information about the mutual
phase relationship of sampling domain 1 (the original sample data) and 2 (the resampled
data). Also, you may want to know the actual frequency relationship between the two
(virtual) sampling clocks,not just the idealized one. Finally, in practical cases (I don't
know what your example was actually for) the sampling clocks might be not completely
stable, so that you could have to factor in what happens to all kinds of signals in
extreme cases when there are slight variations in clock frequency of (one of the) sampling
domains, possibly you 'd need some buffer space to solve those issues, but if you want to
define the practical "resample" function, you might have to take these factors into
account for higher quality cases, and somehow quantify the issues you're solving, maybe
including signal distortion/noise as well as the prevention of potentially dangerous
spurious errors and the change of temporal power in the output signal. Of course depending
on your application.
I for sample rate conversion between various AD/DA convertor domains use "alsa_out|" and
"alsa_in" from the Linux Jack/Alsa/Ladspa toolkit, which can be given various quality
ratings and allows some control over the estimation of the various clock rates and the
response of a sort of control loop for the real time resample computation. Also I
frequently use Mplayer (Linux) which can resample nice enough in integer ratios, and can
deal with small difference between input clock for an external (web) audio(/video) source,
real time clock, and output Digital to Analog converter sampling clock. The alsa_ tools
aren't very big in source code sense, Mplayer resampler is possibly in a directory of it's
own, both are Open Source.
T.V.
_______________________________________________
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp
