On Tue, 18 May 2010 22:56:44 +0200 Fons Adriaensen <fons@xxxxxxxxxxxxxxx> wrote: > On Mon, May 17, 2010 at 02:29:01AM -0700, Ken Restivo wrote: > > > Well, Fons kind of sniffed at Jamin-- "you are mastering through a vocoder" > > Well, that is not really what I wrote: > > Responding to: > > >> I was thinking about tearing into the code for > >> something like Jamin to look at what's done there. Maybe there are > >> better examples for me to use though? > > I wrote: > > > Jamin's FFT based filter is not really a filter, it's a vocoder > > being used as a filter and it has side effects. > > Which is just true. It's also true that changing the window > function and increasing the FFT overlap has reduced the > artefacts to below -80..-90 dB w.r.t. the signal. But that's > not a solution but a cover-up, coming at the expense of a lot > of wasted CPU load - Jamin takes 35% on my 2GHz P4. For what > it is doing 5% would be reasonable. And it doesn't help to > bypass the EQ: it is *always* in circuit, even if the response > is forced to flat when you enable the 'bypass' checkbox. Nor > does it help to improve the atrocious type of responses that > the 'HD' filter will generate if you are just a bit unlucky. > > Ciao, This is rather disturbing. I had noticed that jamin was quite processor heavy, but was unaware that this was unnecessary. Has this been discussed with the devs? Mostly I like the way it sounds and works, and the interface it presents (not that I have much to compare it with). I would rather see it improved than dropped. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
