29 Sep
2010
29 Sep
'10
3:11 p.m.
On Wed, September 29, 2010 5:44 am, fons(a)kokkinizita.net wrote:
On Tue, Sep 28, 2010 at 06:44:09PM -0700, Patrick
Shirkey wrote:
The fact that this *can* be done does not imply it *has* been done
correctly in this case.
I am only interested in figuring out wtf is the real problem with jamin. I
don't doubt that you have found something credible and you can trust in
the fact that your concerns are being looked into from here.
If you want to know more details I will be happy to provide more
information off list.
Otherwise in the interests of keeping a relatively convivial tone I would
like to thank you for spotting the flaws that you have found.
--
Patrick Shirkey
Boost Hardware Ltd.
On Tue, September 28, 2010 8:22 am,
fons(a)kokkinizita.net wrote:
Thas nothing to do with optimisation. The algorithm is wrong. It does
not do what you think it does and what the designers probably intended
it to do. The correct one is not much different, but differs in some
essential points.
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.
Well if this is the case the implementation needs optimisation. That
doesn't change the fundamental nature of the design choice. Don't you mean an optimised implementation of
the filter?
No. I mean a correct implementation.
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.
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.
I'd suggest you stop calling this a linear filter for it isn't.
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.
No. Although a correct implementation would indeed use less CPU.
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.
Then let them speak up. I've posted the technical arguments before and
nor you nor any of your experts has so far commented on them. And as to
my level of experience, I don't think you have any correct idea of that.
I've a nice collection of measurement results for Jamin, maybe I'll
publish a few of them and then your experts can try to explain them.