Ok, so that was a little childish – but the very fact that there is such a debate on the speed of Java caused me a reasonable amount of hesitation before starting out trying to write a multi-channel, realtime audio mixing and effects processing application – with the intention of using it in a live environment. Oh, and the interface was to be a multi-touch table (shown in the last article) – which in itself requires a great deal of processing and computational work to get going. However, I’ve used Java ever since I learned to program, but more importantly, the entirety of the existing frameworks I’d planned on using in order to handle user interaction and multi-touch hardware were already written in Java (Durham University’s SyneryNet Project ).
So, before even committing to the project (a large amount of my final year grade rested on it!) I did some research and discovered that there was a fair possibility that accessing multi-channel audio data from an external (or internal) interface would be possible in Java.
Java provides an interesting set of libraries as part of the javax.sound package. Initially I thought this would be the ticket to success! Using these libraries it’s incredibly easy to access the audio interfaces available to the operating system, select them and access the source and taget lines and read and write data to them. Conveniently this is also relatively platform agnostic, meaning that I could develop the programs on my MacBook and transfer them to Windows systems with more capable hardware for use with the multi-touch surfaces. Fantastic! Or so I thought…
After some trials I was successfully getting data in and out of my simple audio interface. However, there was one limitation that I kept on coming up against. Getting multiple input lines from one particular audio interface seemed to be problematic. My fears were confirmed when I read this article at Java Sound Resources : Current implementations of the Java Sound API do not support multiple TargetDataLines for the same recording source – Doh!
(NB. This was some time ago, new versions of the Java Platform may have removed this limitation – I have not had the time to check, however I feel it worth pointing out in case this in case people experience this problem with their implementations and platforms)
A new approach was needed…
The ASIO Protocol is a protocol that bypasses the operating system’s Audio Drivers and allows for a developer to have access and to control the audio hardware directly. This has numerous advantages – namely very low latency and greater flexibility over hardware control.
APIs to access ASIO data are provided for several languages, and the excellent JASIOHost by Martin Roth provides easy access to any ASIO enabled audio device with a compatible driver installed on a system – using JNI.
(Ahhh, I hear you ask – “What about Mac OSX?” Well, ASIO, whilst is available for the Mac, is rarely if ever used as an almost identical feature set is provided by Core Audio. Annoyingly however, Core Audio Java libraries have been deprecated by Apple for some time and are neither available for or reliably compatible with Mac OSX 10.4 or above)