[LAU] Subject: Albums under a label recorded and/or mixed with Linux
pshirkey at boosthardware.com
Wed Sep 29 13:11:36 UTC 2010
On Wed, September 29, 2010 5:44 am, fons at kokkinizita.net wrote:
> On Tue, Sep 28, 2010 at 06:44:09PM -0700, Patrick Shirkey wrote:
>> On Tue, September 28, 2010 8:22 am, fons at kokkinizita.net wrote:
>> > The implementation is fundamentally wrong. Just send a sine wave
>> > it, measure the result and ask yourself how a *filter* could ever
>> > 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.
> 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.
>> 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
>> > the implementation is fundamentally wrong, the method used does not
>> > filter but it also adds distortion, and most of the CPU power used by
>> > filter is used just to reduce the problems that result from this.
>> How can it be fundamentally wrong if all linear convolution operations
>> be expressed in the the transformed domain, and vice versa.
> The fact that this *can* be done does not imply it *has* been done
> correctly in this case.
>> 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
>> 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
> 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.
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.
Boost Hardware Ltd.
More information about the Linux-audio-user