Re: javax.sound. - application

[Anthony Green <green at redhat dot com>]

On Wed, 2006-09-13 at 21:56 +0200, Ewald Peiszer wrote:
> I finally succeeded in compiling it to native code using gcj 4.1. However, when I invoke the binary (which is basically an audio player that plays two files at the same time) there is the following exception trace:
> 
> Exception in thread "main" javax.sound.sampled.UnsupportedAudioFileException: file type not recognized
>    at javax.sound.sampled.AudioSystem.getAudioInputStream(libgcj.so.7)
>    at untitled1.PlaySoundStream.streamSampledAudio(PlaySoundStream)
>    at untitled1.PlaySoundStream.main(PlaySoundStream)
> 
> This happens if I use mp3-files as well as if I use ordinary .wav-files.

The .wav file support was added post gcj 4.1.  Use Sun or IBM java for
now.

mp3 support will never be an integral part of gcj, and I suspect that
very few Free linux distros will ship with mp3 providers.  You'll have
to find an mp3 provider yourself.

> I also tried to compile it to a .class file (both with suns java 1.5 jdk and gcj 4.1, see makefile below). Then I ran it using
> 
> Sun's java 1.5: works
> gij 4.1: doesn't work (Exception in thread "main" java.lang.IllegalArgumentException: format not supported for stream
>    at javax.sound.sampled.AudioSystem.getAudioInputStream(libgcj.so.7)
>    at untitled1.PlaySoundStream.streamSampledAudio(PlaySoundStream.java:61)
>    at untitled1.PlaySoundStream.main(PlaySoundStream.java:24))
> kaffe (Engine: Just-in-time v3   Version: 1.1.7   Java Version: 1.4): doesn't work (similar error)

Kaffe fails for the same reason gij/gcj does, since we use variants of
the same core class libraries (GNU Classpath).

> It seems to me that I have to have Java 1.5 somehow to run the stuff, but if I compile it natively gcj probably can't use it (gcj 4.1 =~ Java 1.4 regarding javax.sound ? )
> 
> I also find it striking that there are different errors ("file type not recognized" vs "format not supported").

I don't believe the exception messages are standardized as part of the
spec.  However, sometimes we try to make an effort where it makes sense.
You could file a bug against GNU Classpath or gcj on their respective
project pages and see what happens.

> Do you think it is still possible to compile to native code (I would like that for performance reasons, later on it should be possible to decode appr 30 mp3 files at the same time.) Or do you think it actually doesn't matter?

Modern JITs from Sun and IBM generate great code most of the time.
There are other reasons to recommend gcj, but I don't think this use
case of yours is one.

AG