[kaffe] Re: [tritonus-user] Tritonus on kaffe
matthias.pfisterer at web.de
Sun Dec 15 04:05:48 PST 2002
Dalibor Topic wrote:
> Hallo Matthias,
> --- Matthias Pfisterer <matthias.pfisterer at web.de>
> 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
> 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?
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.
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
>>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
> 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.
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.fr
Matthias Pfisterer <mailto:Matthias.Pfisterer at web.de>
Reuchlinstrasse 28 phone +49-711-62 87 12
Java Sound Examples:
Java Sound Programmer's FAQ:
Tritonus, the open source implementation of the Java Sound API:
More information about the kaffe