Hi,
just had a look at this blog and the plugin adapter code reference from there:
Might be interesting for nspluginviewer / KHTML / KDE integration, for example
providing a Phonon implementation for the sound functions.
It's a pity they announce this so late, at an earlier stage of their
development could have allowed to give input on the adaptor API :(
Cheers,
Kevin

2006/10/25, Kevin Krammer <kevin.krammer (AT) gmx (DOT) at>:
Hi,

just had a look at this blog and the plugin adapter code reference from there:

Might be interesting for nspluginviewer / KHTML / KDE integration, for example
providing a Phonon implementation for the sound functions.

I don't think nspluginviewer can use much of this, unless the API also
has embedding extensions (which I didn't find).

It's a pity they announce this so late, at an earlier stage of their
development could have allowed to give input on the adaptor API :(

From KMPlayer's standpoint, it's rather sad that video on the web is
taken over by Adobe web media players.
Also v4l, are they planing for flash based chat or so?

Is this legal if KDE/Qt libs are used? My first impression is that
only code can be used that allows proprietary code to load the lib.
this looks a bit like a back door (ie. build
a lib in GPL with an API that happens to be used by a closed source
application, and because the proprietary site was the one defining the
API, they can't be blamed for that)

Koos

Cheers,
Kevin

2006/10/25, Kevin Krammer <kevin.krammer (AT) gmx (DOT) at>:
Hi,

just had a look at this blog and the plugin adapter code reference from there:

Might be interesting for nspluginviewer / KHTML / KDE integration, for example
providing a Phonon implementation for the sound functions.

I don't think nspluginviewer can use much of this, unless the API also
has embedding extensions (which I didn't find).

It's a pity they announce this so late, at an earlier stage of their
development could have allowed to give input on the adaptor API :(

From KMPlayer's standpoint, it's rather sad that video on the web is
taken over by Adobe web media players.
Also v4l, are they planing for flash based chat or so?

Is this legal if KDE/Qt libs are used? My first impression is that
only code can be used that allows proprietary code to load the lib.
this looks a bit like a back door (ie. build
a lib in GPL with an API that happens to be used by a closed source
application, and because the proprietary site was the one defining the
API, they can't be blamed for that)

Koos

Cheers,
Kevin

Wednesday 25 2006 10:49, Kevin Krammer wrote:
providing a Phonon implementation for the sound functions.

All that needs to be done to achieve "Phonon integration" is to export a DBus
interface to be able to change the audio volume and possibly the audio
device. Which is something that's on my todo list: to fully define how this
part of Phonon works and suggest it for crossdesktop usage on freedesktop.

Is the mixing really a problem anymore? Seems all distro's set up dmix
by default these days which resolves this.

Christian

Wed, 2006-10-25 at 09:15 -0700, Charles Samuels wrote:
Matthias Kretz wrote, on Wednesday 2006 25 5:40 am:
All that needs to be done to achieve "Phonon integration" is to export a
DBus interface to be able to change the audio volume and possibly the audio
device. Which is something that's on my todo list: to fully define how this
part of Phonon works and suggest it for crossdesktop usage on freedesktop.

Er, what about mixing?

I don't want stray nspluginviewers to block my media player (that's what
happens now if you turn off artsdsp for konq plugins)

Charles

kde-multimedia mailing list
kde-multimedia (AT) kde (DOT) org

Wednesday 25 2006 18:15, Charles Samuels wrote:
Er, what about mixing?

Answering to the general "Phonon integration", not the Linux Flash player in
specific:
Linux we have ALSA to do the mixing, which is why ISVs start using ALSA
finally. other systems /dev/dsp will do mixing automatically (like many of
us wanted the Linux kernel to do). all remaining systems we need to use a
soundserver, and I believe PulseAudio is the main candidate there (lacks
testing on my side to be sure though). Having one place to define whether to
use a soundserver, how to access it, and so on is another thing that would be
nice to standardize. But that's orthogonal to the DBus interface for volume
control and device selection, no?