29 Sep
2010
29 Sep
'10
3:44 a.m.
On Tue, September 28, 2010 8:22 am, fons(a)kokkinizita.net wrote:
How can it be fundamentally wrong if all linear convolution operations can
be expressed in the the transformed domain, and vice versa.
If there is a problem it is not due to the fundamental nature of the
linear filter.
But I will query your analysis first because it may be that we are talking
at cross purposes.
IMO what you have identified is the potential for optimising the code.
This is definitely something that should be addressed if it indeed turns
out you are correct in your analysis.
Although I have strong reservations given that 3 different DSP engineers
with qualitatively more experience than you can justify this design
choice.
--
Patrick Shirkey
Boost Hardware Ltd.
On Tue, Sep 28, 2010 at 05:51:09AM -0700, Patrick
Shirkey wrote:
Well if this is the case the implementation needs optimisation. That
doesn't change the fundamental nature of the design choice.
My issue
is that it has an awfully bloated filter (which is suboptimal
according to fons) taking up a lot of cpu-power, while for me it could
perfectly to with a parametric eq (either three bands + shelve or four
bands).
Ok, Thanks for the clarification. I am pretty sure you know already
that
there are two eq modes in jamin? 30 band multi and 3 band parametric
with
shelves. However there is not 4 band. It wouldn't be that hard to add
though if you are serious about it as the three band code is a good
place
to start. Now I am not sure that the 3 band parametric
should be considered a
*real*
parametric or not.
Certainly not. The curvers are different and it's linear-phase while
a normal parametric would be minimum-phase. Also in the LF end the
curves don't correspond to what is displayed for the simple reason
that the FFT filter can't generate them. The same is true for the
30-band EQ (since it uses the same code).
However I have been told that the implementation
of the
linear filter in jamin is fundamentally correct as the FFT/IFFT approach
is the preferred implementation to obtain a more idealized functionality
of those forms of EQ without screwing up the phase.
The implementation is fundamentally wrong. Just send a sine wave through
it, measure the result and ask yourself how a *filter* could ever produce
the broadband junk that this one is adding. A correct implementation of the same filter, still
FFT-based, having
exactly
the same controls, and being able to produce exactly the same frequency
and
phase responses would use much less CPU, and not add this distortion.
Don't you mean an optimised implementation of the filter?
Fons has cause
for suspicion about the current optimisation. It may turn
out that it is possible that we could shave off some cpu cycles. Perhaps
we can get to the bottom of that problem, but as we are using these
large
windows to increase the smoothing across the bands(?) it may be that
there
is no further optimisations that can be achieved.
My concerns are not about the optimisation. For there isn't any. I repeat:
the implementation is fundamentally wrong, the method used does not only
filter but it also adds distortion, and most of the CPU power used by the
filter is used just to reduce the problems that result from this.