Dalibor Topic wrote:
Hallo Matthias,--- Matthias Pfisterer <[EMAIL PROTECTED]> wrote:
I've switched back to C in the directories src/lib/esd, src/lib/alsa, src/lib/common and src/lib/cdparanoia. This should do it for the moment. Note that the inner class issue with the ALSA classes is still pending.My fix for this is to use libtool from current CVS and upgrade out build scripts to latest auto* tools. There are some issues in going that way, mainly increasing the bar for build system developers, and having to fix all the bugs in the build scripts exposed by the upgrade. Of course, if the libraries could be switched to plain old C, that would make my life much easier, I hope. What is the HandleFieldHandler class used for?
It is no longer necessary to build a library in ../common/. I'm now linking the (single, small) object file to any library in the other directories. This is to simplify installation.
The cooked_ioctl directory contains code to read CDs using the Linux "cooked ioctl" interface. As it is superseeded by the cdparanoia based implementation, it is no longer maintained. I keep it as an example of how to structure simple CDDA reading on other operating systems.
gsvorbis contains an incomplete interface to the ogg vorbis encoder. It is not assumed to work.
lame contains, well, an interface to LAME, an mp3 encoder. I suggest to leave it out. All open source implementations of mp3 encoders are illegal, as well as all open source implementations of mp3 decoders. We keep it because it is requested quite often and no open source developer or entity was sued so far. But I think it's best to not proliferate it further. ogg vorbis is a viable alternative gaining market share rapidly, and of better quality. The only drawback is that it is not yet integreted into Java Sound.
And I've deleted the saint directory from the cvs, since it was all legacy.
Ah, the HandleFieldHandler: all low level classes need to keep some handle to some native facility. For esd, it is the file descriptor of the socket connection to the esd server. For ALSA, it is some pointer of type snd_pcm_t* or snd_seq_t*. These handles are stored in instance variables of the JNI classes. Looking into the Java code, you will see members 'private long m_lNativeHandle' or similar. These are used by the native code to store the handles. They are long in Java, because in the future, the native word size or the size of pointers will become 64 bit. It is the code to access these Java fields from the native code that I have generalized in the former C++ class HandleFieldHandler. Now -- after the change to C -- there is a header file src/lib/common/HandleFieldHandler.h that contains C macros to do almost the same.
The Person that implemented the MidiShare support in Tritonus was Stephane Letz. I haven't heard from him for a while. However, he is still subscribed to the tritonus-devel list (note that I moved the discussion there). You can also contact him directly with letz [at] grame.frMidiShare 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/
their web site mentions new versions for Win 200 & OS X , so it might be worth a try. I'll see if I can get it to work.
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
