On Wed, September 29, 2010 5:44 am, fons@xxxxxxxxxxxxxxx wrote: > On Tue, Sep 28, 2010 at 06:44:09PM -0700, Patrick Shirkey wrote: > >> On Tue, September 28, 2010 8:22 am, fons@xxxxxxxxxxxxxxx wrote: >> >> > 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. > > 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 >> 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. > > 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 >> 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. > 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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
