Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Ok, I'm not conviced on the general choice of using JNA over JNI.
Especially, I'm not really sure, if libxine-java _can_ be implemented
using JNA and
if yes, what the consequences woulde be.
Nevertheless, I can understand your situation and I'm acutally quite
confident to think
that using the audio part of xine should be useable via JNA. I guess
it might as well be
a test case to see if porting libxine-java to use JNA is a godd idea.
maybe, we could have a branch/libxine-java-jna-audio for now. I guess
keeping with the
current libxine-java API should be a good idea. Did you already try to
use JNA and
tried to e.g. call printf via JNA or opened xine-lib by calling
Getting xine to play a song is easy as the video part is the tricky one.
I can take the muxine.c code from xinehq.de and remove the video stuff
to build a
minimal xine-based audio player with maybe 100 lines of C code. than,
this has to
be converted to JNA use which will require quite some manual work
(which is done
by SWIG in the current libxine-java). you have to re-type all calls
you want to use with JAN. For an audio player luckily this won't be to
let's see, maybe JNA can be used for libxine-java, but I'm sure an
audio player is
why does aTunes uses xine/mplayer at all? can't java play audio
already? I think I've
seen at least a pure Java mp3 player, or do you want to play other
stuff like ogg etc, too?
On 24.06.2008, at 11:08, Aekold Helbrass wrote:
> Hi, Matthias!! Thanx for great answer!!
> there are few reasons of preferring JNA over JNI:
> 1. honestly, i'm too far from C++ to support it or even compile it for
> my system. I can see some hardcoded path to libxine in java code, and
> it scares me. So for java-only developer JNA is preferred way.
> 2. it is harder to support JNI thatn JNA (as for me of course),
> because you have to recompile it to all (supported) platforms, lib
> versions, have to support your Cpp code and handle env integration
> yourself. If you're working on single project - you may not see any
> difference, but if there are 3 or 4 projects you want to work with -
> it is harder to support this quantity of code and platform variations.
> I am contributing a bits of code to aTunes (http://atunes.org), and
> it's using mplayer as engine, invoking mplayer as child process. I
> prefer xine over mplayer, and aTunes already imports some JNA code for
> all platforms. I am almost sure that aTunes developers will not import
> libxine-java bridge for this purpose. So, i need some your knowledge
> of cpp and libxine to write JNA invocations to libxine to play simple
> audio file and may be setup equalizer. May be after i'll get some
> experience with JNA and libxine, i'll handle other functionality
> myself, but for now...