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

John Check j4strngs at bitless.net
Mon Aug 9 18:06:12 EDT 2004


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.



More information about the Linux-audio-user mailing list