[linux-audio-dev] Re: chebychev

Tim Goetze tim at quitte.de
Fri Nov 1 09:18:00 UTC 2002


Steve Harris wrote:

>On Fri, Nov 01, 2002 at 01:11:44AM +0100, Tim Goetze wrote:
>> 
>> i'll try to work out some tables after checking for fundamental
>> dependency. what kind of windowing would you recommend?
>
>Blackman-Harris has the best sidelobe rejection, which is probably what we

just to make sure we're talking about the same thing:

double blackman (int i)
{
  return 0.42
    - 0.5 * cos (2 * (double) i * M_PI / WINDOW)
    + 0.08 * cos (4 * (double) i * M_PI / WINDOW);
}

is what you mean, right?

>care about here. An important thing is to catch all the components of the
>harmonic, as some will slip into neighboring bins, I'm wondering if that
>isn't one of the causes of the aparent amplitude variation of the
>harmonics.

just did the same plot with applying the above window before the FT;
it does not look fundamentally different. plot is at

http://quitte.de/spectral-evolution-windowed.gif

>Me too. I'm beginig to suspect that commercial amp models aren't really
>modelling the behaviour though.

"aren't really modelling the amp", i understand.

seeing that the proposed chebyshev emulation lends itself much
better for a series of amp models than a 'physical' model makes
me think the same.

>Its not too bad. I hacked up a quick cheby that jumps between 4 harmonic
>sets last night, recalcuating the cheby every sample. It didn't seem
>that slow.

it's probably depending on the size of the I-cache. i guess the 
P-III one is bigger than the k6's, in which case loop unrolling is
more of a benefit in chebpc().

>> yep, best not to go there. however i fear the switched chebyshev
>> output can produce nasty discontinuities. we'll find out.
>
>It does. Well in my randomly picked test set it did, when the harmonic
>amplitudes are real it may be smoother. I'l clean up the code later, make
>it LERP between harmonic sets and send it to you, but I have sleave for
>work now.  

could be we can get away with something like a simple four-sample
xfade, though that could introduce unrelated harmonics. better
than an unmasked discontinuity still. hmmm.

>Interesting. It takes 1/2 as much as a single (optimised) valve here.

did some tests with valve and harmonic_gen at different frames/cycle,
the results seem to support my above cache theory; the chebyshev
is costing a lot less at larger block sizes than the valve. you run
them at 128/44.1 i understand?

>> could this be to do with the 'magnitude normalization' it does?
>
>It could be, I've zapped the normalisation in the ampy one, its also
>possible that its buggy. The cheby maths came from num. rec. which
>is famously full of errors.

good god. know an alternative source for calculating the
coefficients? Bill?

tim




More information about the Linux-audio-dev mailing list