Subject: Re: [linux-audio-user] Re: linux-audio-user] [ANN] jamin-0.9.0 releas
From: John Check (j4strngs_AT_bitless.net)
Date: Tue Aug 10 2004 - 01:06:12 EEST
On Monday 09 August 2004 12:41 pm, Jack O'Quin wrote:
> David Baron <d_baron_AT_012.net.il> writes:
> > On Monday 09 August 2004 11:33,
> > linux-audio-user-request_AT_music.columbia.edu
> >
> > 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.
This archive was generated by hypermail 2b28 : Tue Aug 10 2004 - 01:08:49 EEST