linuxaudio.org

On Tue, 18 May 2010 22:56:44 +0200

Fons Adriaensen  wrote:
> On Mon, May 17, 2010 at 02:29:01AM -0700, Ken Restivo wrote:

quoted text
>

> > 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@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-user