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

[Dalibor Topic]

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.

I proposed to take the bug database down, as noone was
reposonding to the bugs, so it seemed to be a one way
dump for problem reports. That's frustrating for
anyone reporting a bug. So now people are supposed to
report the bugs they find on the mailing list. Usually
they get a response now. That works for us as we don't
get swamped with bug reports. People don't feel
ignored anymore. Plus it is easily googleable ;)

> Since this time, I haven't tried again. My guess is
> that if obstacles 
> like the above are solved, Tritonus will work
> without major problems.

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?

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.

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?

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

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

And of course, any ideas how to get libtool to link
tritonus libs properly are highly appreciated.

best regards,

dalibor topic

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com