On 17 February 2012 15:12, Robin Gareus wrote:
I'm the author of the JACK (JNAJack) binding linked to above. There
should be no reason that it won't work with Clojure, but it's not
something I've tried or AFAIK any other user so far. Let me know how
you get on!
While it's certainly possible to write a useful JACK client running on
the Java VM, it wouldn't be my first choice over C / C++ unless you
have particular requirements of the features of the JVM - JIT
compilation, cross-platform code, managed memory, use of a JVM based
language, integration with existing code, etc. JIT compilation would
probably be the #1 reason, and you won't find many better options
there. It's definitely possible to have live-coded Java DSP code
inserted into the processing graph at runtime - as long as Clojure
produces efficient bytecode, it should be possible to do the same with
it. However, many of the JVM's benefits are also its challenges when
it comes to low-latency audio (as others have mentioned).
If you want to check the performance of the JACK binding, you could
try the audio examples from Praxis - http://code.google.com/p/praxis/
- the project that JNAJack was created for. There's a simple example
and a 4-channel live loop sampler with effects, which I use for
If you do decide that experimenting with the JVM is something you want
to do, a few things come to mind.
* Use a low-pause garbage collector. At minimum try -Xincgc on the
command line for the JVM.
* Keep object allocation (in *any* thread) down. Lots of objects =
lots of garbage = more work for the garbage collector. Incidentally,
you *can* do minimal object creation in the audio thread with the JVM,
due to the Java memory model.
* Try and 'warm up' your DSP code before it hits the audio thread (ie.
run it on a background thread first) to force it to be JIT compiled.
(Praxis doesn't do this currently, so you might notice XRuns when a
particular DSP unit is used for the first time - the other way around
this is to 'exercise' the patch before performing!)
* Read Ross Bencina's article linked to earlier and follow its advice
(it's also linked to in the getting started guide for JNAJack!) In
particular be wary of "synchronized".
> The above constraints rule out [most] garbage-collecting (object oriented) languages. It is NTL possible to carefully program sound
Glad you included the "most" in there! :-) While the consumer JVM is
not real-time safe (though generally soft real-time capable), there
are real-time suitable Java VMs and garbage collectors. Unfortunately
not a lot of them are free. An interesting 5-6 year old article on
real-time software synthesis with IBM's metronome garbage collector is
here - http://domino.watson.ibm.com/comm/research_projects.nsf/pages/metronome.harmonicon.html/$FILE/Auerbach07Harmonicon.pdf
Also, it's worth looking at http://javolution.org/ for real-time
suitable alternatives to classes from the Java standard library.
Neil C Smith
Artist : Technologist : Adviser
Linux-audio-dev mailing list