Hi, On 17 February 2012 15:12, Robin Gareus <[email protected]> wrote: > Anyways, There are JACK bindings for a lot of languages incl. JAVA. The > most recent announcement that crossed this email-list is > https://code.google.com/p/java-audio-utils/ (I don't know if that lib > works with Clojure, but it should) >
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 performances. 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 > processing in those langs but you'll need to know much more about what > happens during compilation and/or interpretation of the language. C has > the least pitfalls. 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. Best wishes, Neil -- Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
