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

[Matthias Pfisterer]

Dalibor Topic wrote:
> Hallo Matthias,
> 
> I've CC:ed kaffe at kaffe.org on this, as I think there
> might be some interest over there, too :)
> 
> --- Matthias Pfisterer <matthias.pfisterer at web.de>
> wrote:
> 
>>Hi,
>>
>>actually, we (Tritonus team) are interested in
>>making Tritonus work with 
>>kaffe. In the long run, it may even be integrated
>>into an open source 
>>implementation of Java (kaffe and gcj seem to be the
>>main candidates).
> 
> 
> Cool. I'd like to turn that long run into a short
> sprint ;)
> 
> 
>>Quite a long time ago I tried to run Tritonus with
>>kaffe. It was with 
>>kaffe 1.0.6. I encountered a bug in kaffe's
>>implementation of the 
>>collection framework that prevented Tritonus from
>>initializing correctly 
>>(exception). I filed a bug report to the bug
>>database of kaffe. But 
>>after months, this bug report was still in
>>'incoming'; it looks like 
>>nobody considered it. And some day, the whole bug
>>database went away...
> 
> 
> After playing around with tritonus, I think I saw the
> bug myself. Our ArrayList.add(Obj) implementation uses
> add(int, Obj) internally, and that one's not
> implemented in tritonus' ArraySet. I've got a trivial
> fix for that, and it will come into kaffe's source
> this weekend.

Yes. Exactly this was the problem.

> My main problem at the moment is getting C++ shared
> libraries and libtool to work together. You are using
> C++ to develop the shared libs (libtritonus*). Kaffe
> on the other hand relies on libtool for dynamical
> library loading. Libtool links the C++ libs with gcc,
> and gcc doesn't automatically add -lstdc++ and -lg++.
> So libtritonusesd can't resolve all symbols. Any idea
> how to solve this in Makefile.am?

As I'm not really happy with the C++ solution, too, I was already 
thinking about switching back to C. Actually, the only reason to use C++ 
is the template class HandleFieldHandler. I got bored of copying source 
code, so I thought the template class would be more elegant. But I saw 
that object code file sizes got bumped from 5 or 6 kB to more than 30 
kB. And with the GNU compiler, templates are not really elegant, too: I 
still have to explicitely put a declaration of each template variant 
into an implementation file. So this should also be possible with plain 
old ugly C macros. As the usage of C++ seems to be one of the major 
problems, I'm now checking if I can switch back soon.
By the way: introducing libtool for Tritonus is also something on my 
wishlist. Perhaps the "upstream sorce" can benefit from your work.

> My other problem is that libtritonusalsa needs javah
> to run on some Alsa* inner classes. I can't seem to
> get the $-character properly quoted in the Makefile.am
> file, and I'm not even sure kaffe's javah properly
> supports them anyway. If the inner classes could be
> moved into proper classes of their own, that would let
> me add support for ALSA in a much easier fashion.

Removing these inner classes is on the TODO list, too. I noticed that 
there is no real benefit from using inner classes. Data hiding has to be 
violated anyway. (For instance, m_lNativeHandle in AlsaPcm.HWParams has 
to be package visible instead of private.) So I agree to changing the 
inner classes. Please tell me if this is high priority.
(And I think the bug in javah has to be fixed anyway.)

> What I have at the moment, is that I've added tritonus
> to kaffe's build system, all the tritonus java libs
> compile, the C++ libraries (except ALSA, because of
> the inner class problems) compile and link,
> SampleAudioPlayer starts but can't link libtritonusesd
> because of "cerr not found", i.e. the
> libtool-over-shared-C++ libs problem mentioned above.
> 
> I'll try linking the C++ parts by hand and see if I
> can get some sound output.
> 
> Send me an email if you are interested in the patch to
> the current kaffe source that merges in tritonus.
> 
> I've also had to make a few patches in order to get
> tritonus C++ libs to compile on g++ 3.2. It was mostly
>  std:: namespace related stuff, and a few jbyte* vs.
> unsigned char* issues. I'll send you the patches once
> I get tritonus to work with kaffe.
>  
> 
>>Portability: Most parts of Tritonus are witten in
>>Java. The parts that 
>>use JNI are access to sound hardware and some
>>advanced encoders (mp3, 
>>ogg vorbis).
> 
> 
> I think I'll leave the vorbis/mp3/etc. stuff out for
> now and just concentrate on getting the basic
> functionality to work. We can merge in the more
> advanced encoders later.
> 
> 
>>As menthioned above, one way to deal with the sound
>>hardware is using 
>>Esound. This makes for easy portability amoung
>>UNIX-like systems: you 
>>just have to port Esound. The other way is using
>>ALSA, which (as far as 
>>I know) is Linux specific.
>>For MIDI, ALSA is the main choice. The alternative
>>is to use MidiShare. 
>>However, the MidiShare part is not actively
>>maintained. I guess that it 
>>will not work out-of-the-box.
> 
> 
> I think I'll go with Esound for now, but having a
> compile time configurable option would be nice. What
> is MidiShare, and how portable is it?

MidiShare is a low-level MIDI API. In theory, it is quite portable. It 
evolved on Macintosh and has also versions for Windows and Linux. I was 
not very happy with it. The windows version only worked for 16bit 
Windows (including Win95, but not WinNT, Win2000, etc.). This is an old 
state, perhaps newer versions have evolved. But the main reason I didn't 
deal with it is that it is not comparative to ALSA's MIDI and sequencing 
facilities. Plus, I think, some personal taste on API design. You can 
get more information on MidiShare at http://www.grame.fr/MidiShare/

> Speaking of portability, are there any plans to
> provide a SDL backend?

No.

> 
>>Let us know if we can help in making Tritonus run on
>>kaffe.
> 
> 
> Are there any automake macros available for tritonus,
> that would make the configuration easier? Something
> like --with-sound=esd,alsa would be nice, and of
> course macros to determine if esd or alsa is
> installed.

Did you have a look at configure.in in Tritonus' top-level directory?
There are some thinks related to this.

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