[kaffe] Re: [tritonus-user] Tritonus on kaffe
matthias.pfisterer at web.de
Wed Dec 18 02:42:31 PST 2002
Dalibor Topic wrote:
> --- Matthias Pfisterer <matthias.pfisterer at web.de>
>>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.
> You could turn the helper functions in common.c into
> static __inline__ functions in common.h. Then you
> would not have to link anything accross directories.
Ok, but doesn't that mean that there will be one object code instance
per source file instead of one per library? It won't matter for esd with
now only two source files. But for ALSA with 20+ source files, it may
make a noticable difference.
>>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
> Yeah, I'll leave mp3 out for all the good reasons.
> Jorbis might be interesting, but I haven't played
> extensively with it yet. I think having gorbis as the
> default Ogg provider, and Jorbis as second choice if
> the ogg tools don't work would be the way to go for
> kaffe, when I've merged in the basic functionality.
Jogg/Jorbis are pure java, so they will work even if no additional
native libraries are installed. There is already a Java Sound service
provider (think of it as some sort of a wrapper layer) for Jorbis. It
has a minor problem with thread safety, but I will fix this and include
this, too. The reason for dealing with native stuff for ogg vorbis at
all is that Jorbis only covers the decoder. For using an encoder, the C
libraries are the only choice. So I think it's rather the Jorbis based
service provider that should be the default and gsorbis the option. At
least this seems appropriate when detecting the build configuration. If
both are present, it can still be debated which implementation to choose
at run-time (for decoding). The run-time configuration system of Java
Sound is flexible enough to separate between decoding and encoding.
(More details later)
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