9 Aug
2004
9 Aug
'04
9:46 a.m.
On Monday 09 August 2004 11:33, linux-audio-user-request(a)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.
A standalone or LDASCP Jamin would be worthwhile for those of us with older
equipment.
9 Aug
9 Aug
12:17 p.m.
True.
But if you have limited computing resources you can first export your
project to a 32/24 bit wav file. Then you can use something like rezound
to play the wave and direct that through jamin for mastering.
And, as far as I understand, jack is very efficient. A standalone
mastering software would have do the audio i/o inside one thread, disk
i/o under another one. This is not that different from having jack
running audio i/o, rezound disk i/o and jamin mastering. Posix SHM does
wonders for process to process communications.
Sampo
On Mon, 2004-08-09 at 14:31, David Baron wrote:
On Monday 09 August 2004 11:33,
linux-audio-user-request(a)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.
A standalone or LDASCP Jamin would be worthwhile for those of us with older
equipment. 
12:43 p.m.
On Mon, 2004-08-09 at 14:31, David Baron wrote:
> On Monday 09 August 2004 11:33, linux-audio-user-request(a)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.
On Mon Aug 9 17:02:18 2004 Sampo Savolainen wrote:
True.
But if you have limited computing resources you can first export your
project to a 32/24 bit wav file. Then you can use something like rezound
to play the wave and direct that through jamin for mastering.
'ecasound -i file.wav -o jack' if rezound's GUI is too hungry.
--
Jan Weil
http://linuxaudioblog.jawebada.de
2:56 p.m.
David Baron <d_baron(a)012.net.il> writes:
On Monday 09 August 2004 11:33,
linux-audio-user-request(a)music.columbia.edu
wrote:
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.
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.
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. 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.
--
joq
8:22 p.m.
On Monday 09 August 2004 12:41 pm, Jack O'Quin wrote:
Or if you're interested in distributed audio, give me a shout.
David Baron <d_baron(a)012.net.il> writes:
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.
On Monday 09 August 2004 11:33,
linux-audio-user-request(a)music.columbia.edu
wrote:
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+.
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. 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. 
9:13 p.m.
On Mon, 2004-08-09 at 11:41, Jack O'Quin wrote:
David Baron <d_baron(a)012.net.il> writes:
Every time I think about doing that I get lazy ;-) Also, on my Athlon
XP 1700+ I can run 12-16 tracks in Ardour (with bunches of active
plugins) to the master bus, master bus to JAMin, JAMin to a stereo track
in Ardour and only use about 40% CPU. The incentive just isn't there
for me. But, if someone wants to do the hard part (I/O) I'll be glad to
add it to the GUI :-)
Jan
On Monday 09 August 2004 11:33,
linux-audio-user-request(a)music.columbia.edu
wrote:
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.
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.
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. 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. 
8:02 p.m.
New subject: [linux-audio-user] Re: linux-audio-user] [ANN] jamin-0.9.0 releas
On Mon, 2004-08-09 at 07:31, David Baron wrote:
On Monday 09 August 2004 11:33,
linux-audio-user-request(a)music.columbia.edu
wrote:
Says who? I don't think the performance hit from doing it in multiple
processes is nearly as bad as you seem to think.
Jack is callback based, all it wants from an app is a pointer to a
function it can call every cycle. Plugins also work this way. Some
program, somewhere, is calling a bunch of functions to make audio. In
That Other OS, it's whatever monolithic music app you happen to like
calling plugin functions, here it's jack calling functions in seperate
apps. It's not all that much different.
-DR-
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.
7593
days inactive
7593
days old
linux-audio-user@lists.linuxaudio.org
6 comments
7 participants
participants (7)
-
Dave Robillard -
David Baron -
Jack O'Quin -
Jan Depner -
Jan Weil -
John Check -
Sampo Savolainen