[kaffe] Re: [tritonus-user] Tritonus on kaffe

[Matthias Pfisterer]

Dalibor Topic wrote:
> --- Stuart Ballard <sballard at netreach.com> wrote:
> 
>>Dalibor Topic wrote:
>>
>>>My current code fits it into kaffe's auto* tools
>>
>>based
>>
>>>build as en extension library, adds a configure
>>
>>option
>>
>>>for the sound backend to use, compiles the java
>>>libraries, and links the C++ libraries
>>
>>accordingly.
>>
>>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++.

> 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 ...

Hi,

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:Matthias.Pfisterer at web.de>
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/
--------------------------------------------------------------