Re: [LAD] Tutorial for programming with JACK

Hi,

On 17 February 2012 15:12, Robin Gareus <robin@email-addr-hidden> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev