On Monday 09 August 2004 12:41 pm, Jack O'Quin wrote: > David Baron <d_baron@xxxxxxxxxx> writes: > > On Monday 09 August 2004 11:33, > > linux-audio-user-request@xxxxxxxxxxxxxxxxxx > > > > wrote: > > > The second stable release (0.9.0) of JAMin - the JACK Audio Mastering > > > interface is now available for download. > > > > 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+. > I run jamin and ardour on a celeron 733 and it's quite usable, but there's a corollary to Moores Law regard application efficiency IIRC. I actually found some research with associated code that addresses the resource limitations on low end machines, but I have to crack a problem with two templates creating an ambiguity with gcc3 before confirming it does what it says. FWIW it's currently implemented as a plug in. > 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. > > 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. > Slack throttle ;D > > 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. Or if you're interested in distributed audio, give me a shout.
