[kaffe] Re: [tritonus-user] Tritonus on kaffe
matthias.pfisterer at web.de
Fri Dec 20 01:43:51 PST 2002
Dalibor Topic wrote:
> --- Stuart Ballard <sballard at netreach.com> wrote:
>>Dalibor Topic wrote:
>>>My current code fits it into kaffe's auto* tools
>>>build as en extension library, adds a configure
>>>for the sound backend to use, compiles the java
>>>libraries, and links the C++ libraries
>>Ouch, a configure option for the sound backend?
>>Isn't that going to make
>>life hard on distributors like Debian, who don't
>>force their users into
>>a single sound system? Will they need to build
>>multiple versions of
>>Kaffe depending on which sound backend is desired?
>>Wouldn't some way of doing it at runtime be
> Currently, I've only got esd to work, so there is not
> much choice anyway: esd, or no sound at all. ;) there
> are a few reasons why I think a sound backend option
> makes sense:
> a) native sound libraries are written in C++. We
> shouldn't require having a C++ compiler in order to
> build kaffe, as that would make porting to systems
> like minix even harder. So there should be a
> convenient way to tell the configure script that we
> don't want to bother with it.
Should be solved now: no more C++.
> b) In order to compile kaffe with sound support, you
> need libesound and esd.h. Many linux distributions
> don't install libesound development files by default.
> I wouldn't want to force people to install a few sound
> RPMs just because they want to use kaffe for XML
> processing, for example. So the default option for
> sound in my patch is "no".
> c) It mirrors the current situation with AWT backends.
> You can only have either Xlib, Qt or no awt at all at
> the same time. Changing that would require a
> significant rewrite of kaffe's java AWT libraries, I
> think. That would be good to have, though, as it would
> in theory allow us to run those nice 3rd party AWT
> implementations like PureJavaAWT.
> d) I'm not sure if it is possible to have several
> different MixerProviders in tritonus simultaneously.
> Matthias, do you know if that works?
> If so, then it shouldn't be hard to add other
> backends, i.e. ALSA by just adding its class file name
> It would be pointless at the moment as the native libs
> for ALSA don't compile on kaffe, due to some problems
> with kaffeh (and me not being able to tell automake to
> quote $ in the Makefile.am).
> I'll better try to post some code tonight, so you guys
> have something to play with. I have to write up a
> massive ChangeLog entry first ...
both compile-time and run-time switches do make sense and should be present.
To start with the run-time ones: The configuration system of Java Sound
works by scanning the class paths (boot, extension, user) for
configuration files like
META-INF/services/javax.sound.sampled.spi.MixerProvider. This is done
using the method Classloader.findResources(String). Note that it's
'Resources', no 'Resource', so multiple entries can be found. For all
configuration files found, the file is read. Classes mentioned in the
configuration file are instantiated with Class.forName(). All classes of
one type of configuration file form an ordered list of Service Providers
of the respective type.
This leads to the practice of packaging (for instance) a Mixer
implementation together with a configuration file naming just this
Service Provider. The resulting .jar file can just be added to or
removed from the class path. This is why Tritonus routinely builds 10+
jar files: one for esd, one for ALSA, one for standard audio file
readers and writers, one for the GSM codec, and so on.
In theory, it is possible to have any number of service providers of the
same type. For mixer providers, there is an obvious restriction: It
can't work if multiple mixer implementations compete for exclusive
Compile-time configuration: this is useful for the reasons stated above:
not forcing too much build dependencies. There should be either an
option like --with-sound-backend=esd,also,... (multiple entries should
be possible) or an automatic detection of available libraries that can
be linked against.
Distributions could be broken in packages as it is common for sound
programs with different backends:
... where the vlc-* packages only contain the plug-ins (Java Sound
speak: 'service providers').
Matthias Pfisterer <mailto:Matthias.Pfisterer at web.de>
Reuchlinstrasse 28 phone +49-711-62 87 12
Java Sound Examples:
Java Sound Programmer's FAQ:
Tritonus, the open source implementation of the Java Sound API:
More information about the kaffe