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

[Matthias Pfisterer]

Dalibor Topic wrote:
> --- Matthias Pfisterer <matthias.pfisterer@web.de>
> wrote:
> 
>>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
>>operating systems.


> 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

-- 
Matthias Pfisterer	<mailto:Matthias.Pfisterer@web.de>
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/
--------------------------------------------------------------