Hallo Matthias, I've CC:ed [EMAIL PROTECTED] on this, as I think there might be some interest over there, too :)
--- Matthias Pfisterer <[EMAIL PROTECTED]> 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 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe