Java Sound & Music Software for Linux, Part 1

I've wanted to write this article for quite a while. Over the years I've noted that Java-based music and sound applications have increased in number and quality, yet no comprehensive list or summaries have covered these advances. And so at long last I present this survey of music and sound applications that require Java. The presentation follows no particular order, but in this first part I'll begin by questioning the use of Java in sound and music applications development, followed by a brief look at Java's internal audio and MIDI capabilities.

Why Java ?

Out of the many programming languages available to sound and music software developers, why choose Java ? Here is a short list of reasons that occur to me :

Java is a cross-platform solution - The "write once, run anywhere" mantra originated with Java, and as long as a JVM (Java virtual machine) exists for the platform the language lives up to the creed. I've run jar files on Linux that were intended for Windows, sometimes with perfect results. Mileage will vary with the number and type of platform-specific components required (e.g. a Windows-only MIDI driver for Java).

Java has an internal audio/MIDI API - The Java Sound API provides a built-in mechanism for handling audio and MIDI events, files, and streams. The applications programmer can write to the API instead of the machine-specific hardware and/or its audio subsystem.

Java has its own GUI components - While the default look & feel isn't exactly awe-inspiring the Java GUI toolkit can be coaxed into looking very fine indeed (see Figure 1).

Java is an object-oriented language - If I learned anything while studying the Lisp-based Common Music I learned that object-oriented languages are Da Bomb when it comes to music composition software. Part 2 of this article shows off the variety of Java music and sound applications, and that list includes some very powerful software for creating and transforming musical events and patterns.

Java is widely deployed - Java is available for the major computing platforms, it has a long and strong track record of use in many computing scenarios, and it has the force of a major business (Sun Microsystems) behind it.

Java is now FOSS - At long last Sun saw the light and GPL'd Java. Hallelujah !

The language does have its shortcomings, and I address some of those deficiencies in this article. However, as I researched this material I discovered that Java has quietly "caught on" with a great number of programmers in the sound and music domains. The quality of their work speaks for itself, but it also speaks for Java's utility and appeal. We'll begin our examination of this appeal by taking a brief look at the Java Sound API.

Figure 1: blue, a Java-based production environment for Csound

Java Sound

Java Sound has been a standard component in Sun's Java from version 1.3 onwards. The API supports common audio operations such as playback, recording, and mixing, and its MIDI capabilities include support for MIDI event sequencing and MIDI synthesis. Java Sound targets the normal user's typical desktop sound requirements, such as media playback and relatively lightweight production capabilities. Synchronization methods such as SMPTE or MTC are not supported, nor is JACK, but these factors are limiting only if the target application requires them.

Java supports the OSS /dev/dsp device as its default audio device. Java also supports the ALSA sound system, but that support comes with a caution. I was mystified when an application appeared to be working perfectly, yet no sound came out of my speakers. With help from members of the Linux Audio Developers list I discovered that Java didn't like my primary ALSA audio device, an M-Audio Delta 66, so it rolled over to the next available card, an SBLive. However, I don't use that card for audio, I only need its hardware MIDI ports, so I was stumped and soundless until I realized my mistake and hooked some speakers to the Live's audio output.

Apparently Java finds no suitable mixer device for the Delta 66 (a pro-audio card), so it selects the next device until it finds one that does have such a mixer. Clearly this behavior is intended, but in this regard Java needs to deepen its support for all devices supported by ALSA. Better yet, Java should provided complete support for JACK. Alas, it seems that direct support for JACK is not coming soon, according to this comment from the Miscellaneous FAQ page on the Java Sound Resources site :

3.4. Why is there no artsd/esd support in Java Sound?

In Florian's and my opinion, mixing daemons like artsd, esd, JACK, rplay, NAS, yiff, ... are hacks that work around a shortcoming of the device drivers. We feel that mixing should be done either by the soundcard hardware or in software by the device driver. For Windows (DirectSound) and Solaris, this is self-evident, while Linux is lagging behind. The OSS driver model is obsolete technology anyway, and ALSA can do mixing in software with the dmix plug-in. With this state of affairs, all these discussions about mixing daemons could be settled once for all. Never again would a sound program have to reinvent the wheel with output plugins for /dev/dsp, ALSA, esd, arts, [you name it]. This would be a very efficient solution in terms of using (vs. wasting) programmer time. It would even enable the coexistence of several mixing daemons for backward compatibility. So why not do the obvious, elegant, technically clean, (human) resource saving?

Similar remarks regarding ASIO lead me to believe that Java sound development should consider the requirements of professional-grade audio production. These days, those requirements certainly include ASIO for Windows and JACK for Linux and OSX. Without this support Java sound applications may be useful in many regards, but their value will be much reduced in settings that require low-latency and free connectivity.

Despite that lapse re: JACK and ASIO the Java Sound Resources site is still the definitive resource for Java Sound as implemented through Java 1.5. Check it out for code examples, applets and applications, and a very comprehensive set of FAQ pages.

Figure 2: The Gervill synthesizer

The Java Sound API also provides an interface to an internal MIDI-controlled synthesizer. This synth renders a set of General MIDI instruments contained in a soundbank found at $JAVA_HOME/jre/lib/audio. Many Java audio applications use the internal synthesizer, but the default bank has a rather mediocre sound quality. I suggest replacing it with the deluxe set available from the Java Sound API: Soundbanks page, the quality is much better. To further improve this support Sun has developed a new internal synthesis engine, known as the Gervill synthesizer (Figure 2), and it recently reached its 1.0 release stage. Gervill's features include support for DSL and SoundFont2 sound sources, the General MIDI patch map, and the MIDI tuning standard. I tested the synth in its standalone version, it worked well, and I think it will be an improvement for the system. (Aside to the developers: It would be even better with JACK support.)


The Tritonus project is a clean-room implementation of the Java Sound API, originally written to provide an open-source audio programming interface for Java. Tritonus enhances and extends the original API with a plugin system that adds amenities such as a CD audio ripper, an OGG decoder, support for GNOME's esd sound daemon, and support for ALSA's mixer and sequencer. Project development has been slow for a long time, and Sun's decision to open-source Java has effectively negated the need for Tritonus. However, the Tritonus plugins are still useful and should work with the Java Sound API through Java 1.5.


Jens Gulden's JJack unites the Java sound system with the JACK audio server. The package provides four methods for this unification, including a native Java Sound driver for JACK, a shell environment for JJack clients, a provision for designing Java Beans with JJack, and the use of the JJack library when compiling standalone applications.

I compiled and tested JJack on both machines here at Studio Dave, using only the first method. I installed jjack.jar and jjack-clients.jar in $JAVA_HOME/jre/lib/ext and copied to /usr/lib. According to the package instructions JJack would be recognized and started automatically. Both systems indicated that it started all right, but alas, JJack instantly zombifies on my JAD 1.0 system (Java 1.5). I'm pursuing some possible resolutions on that machine. JJack appeared to be much happier on my 64 Studio box, but only after I switched JACK's configuration from my Delta 66 (hw:0) to the machine's second card, a SoundBlaster PCI128 (hw:1). Alas, QJackCtl reported a steady stream of xruns until I remembered that the PCI128 performed much better in simplex mode. I switched modes, the xruns diminished significantly, and they were reduced even further when I raised the JACK buffer from 512 to 1024 samples.

I thought I had resolved all problems with JJack, but when I tried recording from the JJack port into ecasound I created only empty files. Using strace I looked further into the problem and discovered that Java was still not accessing the ALSA devices and was rolling back to use /dev/dsp. Thus, although JJack was running as advertised it was still not receiving the audio stream from Java's internal sound handlers. I've contacted the author and I plan to work with him to fix these issues, but again I say that it would be in Sun's greater interest to support JACK directly. As the second part of this article will show, Java sound and music programs are flourishing, and giving them the gift of JACK connectivity would enrich the entire Java community of audio/MIDI applications developers and users.


Similis sum folio de quo ludunt venti.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Java still broken

Speaker to Vegetables's picture

Since my main sound card is a Delta and I use Jack for nearly all recording and editing, for my purposes this article can be summed up as: don't waste your time on Java-based software, Java is still completely broken. Thanks for the tip.

maybe, maybe not

Dave Phillips's picture

I won't say it's completely broken, but I will agree that without JACK support JavaSound's applicability is severely crippled in the modern Linux audio ecology. I've been testing and using a variety of Java sound & music apps lately, and almost every one of them could be significantly enhanced by JACK connectivity. I'm happy about Sun's decision to GPL Java, but I'll be ecstatic if/when they get around to fitting JavaSound with JACK.

Meanwhile, there may be a way around the limitation we both face (though I have the workaround with my second card). I'm looking into the possibility of using .asoundrc to spoof Java into thinking that the Delta 66 has a typical consumer-grade mixer section. Alas, I've got no joy as of yet. Perhaps another user can suggest a working solution ?

Also, it apears that I've misunderstood JJack's intentions. I hoped that it would work as a "magic bullet", but so far I've had no remarkable success with it. The JJack author has dropped out of touch, and I confess to being a bit bewildered by how it's actually supposed to work. I'd like to hear from any users who have tried JJack, regardless of success or failure.


Dave Phillips

Similis sum folio de quo ludunt venti.

Java Sound API deficiencies

Anonymous's picture

I spent a bit of time with the Java sound API internals trying to find an easy way to add a Jack interface.

Not so doable.

I think the Java sound API needs to be rewritten to allow the ability to easily and dynamically load drivers which include the current ones. Think of 'intermediate' dynamically loadable Java drivers for each interface that contain the details and ideosyncracies of that device so as to keep the Java Sound API away from unwelcome assumptions and limitations.

Maybe you already know, but

Alessandro's picture

Maybe you already know, but there is also TuxGuitar, a Java software which aims becoming a valid alternative to GuitarPro and/or PowerTab, and that I find immensely useful on Linux (where there was not a valid substitute for one of the programs cited above).

Da Bomb?

G's picture

I'm an OO-programmer (and think Java is great), but have no idea why that would matter to the user of an application.

Perhaps you'll have a better

Dave Phillips's picture

Perhaps you'll have a better idea when you read Part 2. :)

But to clarify: OO happens to be an excellent representation for musical ideation and process. Inheritance and encapsulation are familiar methods to the composer, and OO languages are a "good fit" to the practice of music composition. Read a good book on music composition, I wouldn't be surprised if the methodology seems rather familiar to you. A great start might be Rick Taube's "Notes From The Metalevel", the language there is Lisp but it demonstrates my point nicely.

Btw, not every music application has a shiny surface, and even some that do still provide a language interface. Some music applications *are* languages (Common Music, Csound, SC3, JMSL, etc).

Similis sum folio de quo ludunt venti.

Free Dummies Books
Continuous Engineering


  • What continuous engineering is
  • How to continuously improve complex product designs
  • How to anticipate and respond to markets and clients
  • How to get the most out of your engineering resources

Get your free book now

Sponsored by IBM

Free Dummies Books
Service Virtualization

Learn to:

  • Define service virtualization
  • Select the most beneficial services to virtualize
  • Improve your traditional approach to testing
  • Deliver higher-quality software faster

Get your free book now

Sponsored by IBM