Java Sound Resources: FAQ: Tritonus

Tritonus is an independant, clean-room, open-source implementation of the Java Sound API. (Matthias)

To understand this issue, note that there is a distiction between the Java Sound API specification and implementations of this API specification. The specification is what you can read when you open your browser and point it to the javadocs of the javax.sound.* classes.

Then, there are implementations. Currently, there are two: one in the Sun JDK 1.3/1.4 and Tritonus. Both try to follow the Java Sound API specification, and both are only moderately successful in doing so. As usual, different implementations have different bugs. In addition, both implementations have areas where they do not implement the specification at all. For instance, both implementations do not implement Ports. Further, there are areas where the implementations take different approaches. For instance, the Sun implementation has a software synthesizer buit-in and cannot work with hardware synthesizers cleanly. Whereas Tritonus relies on hardware synthesizers, where the handling is really good, or utilizes software synthesizers already installed on your system (which does not work overly well).

If you are concerned about a specific part of the specification, the best idea is to search this FAQ, scan the mailing list archives or search in Sun's bug database. (Matthias)

"Write Once, Run Anywhere" is (sometimes) true for application programs written in Java. However, it is not true for the implementation of the Java Virtual Machine (VM). The VM has to hide system specific details and abstract to a system independent behaviour. So obviously, you can't implement a Java Virtual Machine on top of a Java Virtual Machine. Somebody has to do the ugly job of interfacing to the operating system. That's why a JDK version runs either on Solaris, or on Linux, or on Windows, or on another operating system.

Parts of Tritonus have a function similar to the VM: interfacing to operating system APIs (in this case, mostly the soundcard and its driver) and hiding the details. So for these parts, the story is the same: they can't be system independant. Other parts can be implemented in pure java, so they run on different operating systems, including Windows. See How to use Tritonus. (Matthias)

Using Tritonus under JDK 1.3.0 is a bit tricky. The point is that by installing Tritonus you are just adding Tritonus' mixers, converters and other service providers to the ones of Sun's Java Sound implementation. Especially, Sun's mixing engine is still the default mixer. To use Tritonus' mixers, you have to select the mixer in your program manually: get the respective Mixer object from AudioSystem, and allocate the lines from this Mixer object. The same is true for MidiDevices. It's possible to use Tritonus' javax.sound.* classes by putting them into the boot classpath *before* rt.jar. But this still leaves you with Sun's service providers. Getting rid of them required to change the service provider configuration files inside rt.jar or other, even more fancy measures. The alternative way out of the hell is to use a JDK 1.2.X, where Tritonus is the only Java Sound implementation. (Matthias)

You may need to use the command line options to set the mixer to use. For instance: AudioLoop -M "Esd Mixer". Check the exact spelling of the mixer name with 'AudioLoop -l'. (Matthias)

You can achieve this by putting the Tritonus .jars into the bootclasspath before rt.jar: java -Xbootclasspath/p:tritonus_core.jar:tritonus_share.jar ...

Make sure to include the correct path to these two files in the statement. Also note that this will not remove the service provider components of the JDK. (Matthias)

For the core classes (javax.sound.*), you can invoke the VM with the option -verbose:class. Then, look from which .jar file they are loaded. (Matthias)

Yes, it is available in a CVS repository. See CVS repository. If you try to compile Tritonus yourself, be sure to read the file INSTALL for instructions. See also Why is it not possible to compile Tritonus with a compiler of JDK 1.4 or older? (Matthias)

Tritonus is an implementation of the Java Sound API. To keep your programs portable, you should only use this API (the package javax.sound). However, if you are interested in the design of Tritonus, have a look at the javadocs. (Matthias)

Both are sequencers that implement the Sequencer interface of the Java Sound API. The difference is the implementation: The "Tritonus ALSA Sequencer" uses the sequencer of ALSA that is running inside the kernel. This sequencer can only be used on Linux. It has very reliable timing. On the other hand, the "Tritonus Java Sequencer" is implemented in pure Java. In theory, it runs on any operating system. In practice, its performance depends on the implementation of System.currentTimeMillis() or the availability of other clocks and the implementation of Thread.sleep(). See currenttimemillis and Q: 6 (Matthias)

Both implementations use ALSA for MIDI I/O. However, while the JDK uses ALSA's "rawmidi", a low-level interface, is Tritonus based on ALSA's sequencer, a high-level interface. The drawback of using rawmidi is that devices are opened exclusively. So native applications using the rawmidi interface and the JDK can block each other. On the other hand, the high-level interface as used by Tritonus allows shared access to the device. This enables multiple applications to run concurrently.

Tritonus can also use ALSA's sequencer queues to implement Sequencer. The JDK has a pure java Sequencer implementation, similar to the "Tritonus Java Sequencer" (see Q: 10). (Matthias)

Well, the directory is called test, not examples. These programs are used to test implementation internals. And yes, some of them are outdated. To test a Tritonus installation, you can use the programs AudioPlayer and MidiPlayer. (Matthias)

Yes, if you are using Linux. In this case, install ALSA and use the ALSA plugin from Tritonus Plug-ins. (If you are on an x86 architecture. Otherwise you have to compile Tritonus yourself.)

If you are using a different UNIX-like system, you may try with running multiple Esound instances. However, this looks quite tricky to me. I've never tried it. (Matthias)

Some parts of Tritonus already use new language features of 1.5, especially generics. You can either use a compiler that is capable of compiling such code or check out an older CVS state of Tritonus. There is a CVS tag 'JDK_1_4_COMPATIBLE' that you can use to get a version that compiles with a 1.4 compiler. You can use the following command to check out with this tag:

(Matthias)

No. You are welcome to volunteer. If you are interested in this task, send a mail to the tritonus-devel mailing list. (Matthias)

Florian originally implemented "sample and hold" and found the quality inferiour. The current algorithm is linear interpolation. Resampling is not implemented. The method setConversionAlgorithm() may (or may not) work, but you will gain no advantage from changing the algorithm from linear interpolation to sample and hold.

We do look for volunteers implementing a resampled/filtered conversion algorithm. It is also planned to use Audioformat.properties to choose the conversion algorithm. (Matthias)

Dowload the pre-compiled .jar of the plug-in you want to install from Tritonus Plug-ins. Note that most plug-ins require to install tritonus_share.jar, too, which contains some base and utility classes.

It is recommended to put the .jar files into the extension classpath. In order to do so, copy them into the extension directory of your JDK installation. On UNIX, the extension directory is typically something like /usr/local/jdk1.5.0/jre/lib/ext. On Windows, it is typically something like C:\jdk1.5.0\jre\lib\ext. Note that putting such .jar files into the user classpath has its pitfalls: using the '-jar' option (as in java -jar jsinfo.jar) OVERRIDES the user class path. Therefore, the following doesn't work (nor does the equivalent using the CLASSPATH environment variable): java -cp tritonus_share.jar:tritonus_gsm.jar -jar jsinfo.jar

For more details on classpaths, see 'Setting the class path' in the JDK documentation (Solaris/Linux, Windows). On Troubleshooting, see also If it doesn't work. (Matthias)