On Tue, September 28, 2010 8:22 am, fons@xxxxxxxxxxxxxxx wrote: > On Tue, Sep 28, 2010 at 05:51:09AM -0700, Patrick Shirkey wrote: > >> > 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. Well if this is the case the implementation needs optimisation. That doesn't change the fundamental nature of the design choice. > 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. > 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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
