JOGL and JMF Compatibility

Hi Everyone,

I am having some problems using both JOGL and JMF within the same application.

I have written some code which uses JMF to play an audio file - and have tested this - it works fine.

However, if I add the native libraries for jogl.jar onto the build path, then the same application throws the following error:

Unable to handle format: mpeglayer3, 44100.0 Hz, 16-bit, Stereo, LittleEndian, Signed, 24000.0 frame rate, FrameSize=32768 bits

This does not occur if I remove the native library path to jogl from my build path in eclipse.

I would be most appreciative if anyone had any experience with this problem - or suggestions for a solution?

Many, many thanks,

Peter Kirkland

Can you provide a small test case which shows the problem? I believe we’ve done simple examples in house that appear to work.

Also, what platform are you on? What exactly do you mean by “add the native libraries for jogl.jar onto the build path”? Do you mean adding them to the run path? Can you reproduce this behavior outside of Eclipse with a command-line invocation of the JVM specifying both -classpath and -Djava.library.path?

Hi Ken,

Many thanks for your reply.

In the interim, I have noticed that adding “c:\windows\system32” to the “native library location” for jmf (i.e. adding it to the run path), removes the problem - and audio files load in correctly.
I think that the native libraries for jmf are installed into this location (jmfjawt.dll) - however I am still puzzled why I need to add this location onto the run path whenever I’ve added the jogl native libraries onto the run path? (If the jogl natives are not added, it is not required)

[quote]what platform are you on?
[/quote]
I have experienced this on both Windows XP and Windows Vista. Both using eclipse, on JDK 1.5 and 1.6.

[quote]What exactly do you mean by “add the native libraries for jogl.jar onto the build path”? Do you mean adding them to the run path?
[/quote]
Yes - apologies for the confusion. I mean adding them to the run path. (i.e. -Djava.library.path)

Unfortunately I don’t have much time at the minute, so cannot provide a small test case, or attempt the command-line invocation, however I will attempt this later, thanks for the suggestion.

Thanks,
Peter

I’m not 100% sure, but if -Djava.library.path works like -classpath, then if you specify it, it overrides the default picked up from the environment. On Windows -Djava.library.path is initialized from the PATH environment variable, where -classpath is initialized from the CLASSPATH environment variable.