[linux-audio-user] Re: linux-audio-user] [ANN] jamin-0.9.0 releas

[David Baron]

> > Problem with Jamin is that is a process to process thingie. Another
> > program, eating precious CPU cycles, must be playing and pre-processing
> > the audio to feed Jamin. I just do not have the CPU guts to run this way.
> > Under that other OS, I can run this type of software as a standalone
> > (file-to-file) or DX/VST plugin OK. The three-process (playing app, jack,
> > Jamin, jack) system is just not efficient.
>
> While the JACK overhead is measurable, I doubt it's your main problem.
>
> JAMin uses an FFT for linear-phase filtering.  This is quite expensive
> in CPU, but sounds great.  We made that tradeoff consciously, choosing
> sound quality over CPU cost, recognizing that some older CPUs would
> have trouble keeping up.  Moore's Law is rapidly fixing that problem
> even as we speak.  JAMin only uses about 25% of my relatively old
> Athlon XP 1800+.
>
> IIUC, most Windows mastering applications use lower-cost non-linear
> filters, so they run comfortably on low-end hardware.  That is a
> reasonable business tradeoff for them to make.

Yup. I use several FFT based plugins and the eat it up quite nicely. They get 
some improvement by using assembler rather than C++ for the math but they 
still eat it up. BUT, I can use them. If I use the worst ones or too many, 
then I need to destructively apply. Great examples are "CloneBoy" and 
"CloneEnsemble". I can make MIDI choirs sing (and well!), but not "live" if I 
am using both of these.

> If your machine is close to being able to hack it, try using a large
> JACK buffer size (-p2048 or -p4096).  This reduces both JACK and FFT
> overhead.  Mastering does not require low-latency operation, anyway.

My Qjackctl show 46ms latency now. I run my Windows junk at > 100ms routinely 
so as not to run afoul of plugins that neglect to use the lookahead calls. 
What do I set that here as well and give it a try.

> > A standalone or LDASCP Jamin would be worthwhile for those of us with
> > older equipment.
>
> You're welcome to contribute one yourself.  The GUI is far too complex
> for LADSPA, but there's nothing particularly complicated about adding
> file I/O to JAMin, itself.  We just didn't feel like working on that.
> There are so many good JACK-based solutions already available.

I might just try it. I fail to compile anything that wants QT3 (I do have it 
and cannoct figure out why the ./configure cannot find it) but other stuff 
will usually compile. If I do and can get that working, how do I contribute 
it to the project?