On Mon, Oct 20, 2008 at 10:42 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Miller Puckette wrote:
Also the default upsampling algorithm is incorrect - if you upsaple by 2, for instance, incoming signals get interleaved with zeros, which does not result in a unity DC gain. I've been fretting over whether this should be changed (incompatibly!) to make it "correct' or just leave it wrong.
personally i would just change it. if somebody relies on a certain upsampling algorithm, they should explicitely specify so in the creation arguments. (or even better, use a separate object that fills the gaps in the zero-padded signal with something more sophisticated)
only tricky part about it, is that the method to perform interpolation/extrapolation on the zero-padded signal depends on the upsampling ratio. A separate object would have to be passed (or query for) the upsampling ratio.
There is a method by fft, that will perform extrapolation as well as interpolation during upsampling--it's limitation is that the points at the ends of the block may not have continuity between blocks (OTOH--this problem is always there). For an upsampling ratio of k and original size n: Take the fft of the signal at the original rate, multiply by k, pad the end with k*(n-1) zeros and take the ifft. O(kn*log(kn))
4-point interpolation is nearly trivial--there's still the problem of what to do at the end points. However, given that it has a fixed rate, coefficients for interpolation can be calculated beforehand. Then, it takes 4 multiplies and 3 adds per zero. Total: 4*n*(k-1) multiplies and 3*n*(k-1) adds.
Both methods could be optimally coded by omitting the zero-interleaving step. But it comes down to--what representation is most useful? Why go to all the trouble of interpolating, if what you really want is a zero-interleaved signal? Why zero-interleave first, and interpolate second?
So, I would favor an optional creation argument for specifying an interpolation method in place of the zero-interleaving step.
Chuck