Dalibor Topic wrote:
--- Stuart Ballard <[EMAIL PROTECTED]> wrote:Dalibor Topic wrote:My current code fits it into kaffe's auto* toolsbasedbuild as en extension library, adds a configureoptionaccordingly.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
preferable?
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++.
Hi,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 to META-INF/services/javax.sound.sampled.spi.MixerProvider 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 hardware access.
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:
vlc
vlc-alsa
vlc-arts
vlc-esd
xmms
xmms-alsa
...
... where the vlc-* packages only contain the plug-ins (Java Sound speak: 'service providers').
Matthias
--
Matthias Pfisterer <mailto:[EMAIL PROTECTED]>
Reuchlinstrasse 28 phone +49-711-62 87 12
D-70176 Stuttgart
GERMANY
Java Sound Examples:
http://www.jsresources.org/examples/
Java Sound Programmer's FAQ:
http://www.jsresources.org/faq/
Tritonus, the open source implementation of the Java Sound API:
http://www.tritonus.org/
--------------------------------------------------------------
_______________________________________________
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
