> > 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?
