Phonon java binding

[Aekold Helbrass]

Ok, I'll try to answer to all...

>> - size of libs about 20MB. it is very unlikely to use 20MB of libs
>> with program about 20KB.
>> - Jambi is Qt dependent, version compatibilities could be and issue.
> Phonon is Qt-dependent, so this is not an argument.

As i understand, Phonon is part of Qt, so there will be no issues of
version compatibility between Phonon and Qt, am I right? While if i
want to distribute Jambi with my application - Qt may be version
higher or version lower, and Jambi looks like following Qt, and I
cannot be sure about compatibility between different Qt<=>Jambi
versions.

>> - Jambi is autogenerated wrapper, not quite a binding, and it does not
>> helps to understand how Phonon works internally.
> Jambi is not an autogenerated wrapper. There's a binding tool, true, but it's
> tweaked so that the end result is proper (it's no more a binding than PyQt,
> Qyoto, and any other Smoke-based bindings).
>
> There's a lot of Java code in Jambi too that is not generated.
>
> Phonon is also written in C++, so if you want to understand how it works
> internally, you need to read the C++ part of it.

Hm, I understand. Ok, let Jambi to be binding rather than wrapper. But
I don't want really to know how Phonon works internally, I want to
know public API of Phonon. Guys from Amarok and Dragonplayer are using
it, are they?

>> So my question is still here, is there single *.so file to use and is
>> there something similar to xine.h to know what to use?
>
> There are two problems with that question.
>
> First and foremost, it's a contradiction in your terms. An *.so file is
> platform-dependent, so you can't use it (see your first argument above, which I
> left quoted). libxine.so is also 324k in size, so it's already more than 10x
> larger than your 20k application, thereby negating your second argument.

I just wanted to make it simplier. JNA allows me to use liblaries in
platform-independent way. So doing Native.loadLibrary("xine",
Xine.class) links libxine.so under linux and xine.dll under windows
(if xine will ever be ported of course).

> As for the second problem, this is the kde-multimedia mailing list. We can
> help you with Phonon, not Xine.

Xine was just an example, xine.h shows me everything I can use and
bind, may be there is some *.h files for Phonon to? I have already
wrote xine binding, and I need help with Phonon, not xine.

> If you want to load the libphonon.so file (515k), remember that it links to
> QtCore (3.1M), QtGui (14M) and QtDBus (510k). So you still need to handle that
> much space.
>
> In other words, Jambi is worth your time.

I totally agree about Jambi if I want to write a fully-integrated KDE
application in Java. More than that, I like Qt a bit more than Swing
because of Sun ignoring the desktop. But there is a problem with
non-KDE sound applications, including Amarok 1.4. It is not using
Phonon, it is using xine directly. And when it plays - no other KDE4
sounds can reach sound system. In other direction - when KDE4 plays
something - Amarok 1.4 fails. Same problem with aTunes.org audio
player, written in Swing. There is possibility to choose player engine
in aTunes player (almost the same as in Amarok 1.4), MPlayer and Xine
currently supported. For aTunes to work properly on KDE4 I'd like to
write Pnonon pure-java binding, without making aTunes to rely on
Jambi. Because of this I need to know some public API of Phonon, and
something like phonon.h could be totally enough for me. After writing
Xine engine for aTunes I know how to check libphonon.so existance, may
be I'll find some APIs myself, but my C++ understanding is limited.
And I ask for your help to show me where to dig for Phonon public
APIs.

On Thu, Jan 22, 2009 at 8:35 PM, Kevin Krammer <kevin.krammer at gmx.at> wrote:
>> I am java developer and it is interesting for me to develop some java
>> bindings for phonon, so java apps will work correctly with phonon
>> sound system. And I need a bit of your help...
>
> Judging by the other postings in this thread I guess that this is rather a
> misunderstanding.
>
> Phonon is not a sound system it is a multimedia API.
> If a Java developer wants to use this API, Jambi is the way to go.
> If a Java developer wants to do their own API, they probably want to interface
> with the different multimedia processing frameworks directly.
> If a Java developer wants to just code a multimedia using application, they
> probably want to use the Java Media Framework.

When you're using KDE4 desktop I can see no difference between
multimedia API and sound system, because Phonon blocks sound from
other applications. To make everything work properly - I should use
Phonon (who is using xine or any other engine itself) but I should not
use Xine directly, because all other KDE4 apps will fail. More than
that, as for me JMF is weak and is not an option to use for audio
player any way, I'd rather use MPlayer wrapper or Xine binding to have
full support of audio formats and features like equalizer.