[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: make_it_cool: kdelibs/kdemm
From:       Ryan Gammon <rgammon () real ! com>
Date:       2005-03-18 21:56:47
Message-ID: 423B4E9F.5060907 () real ! com
[Download RAW message or body]

Matthias Kretz wrote:

>Here's the Requirements & Specification document I'm working on.
>I put it here so that you can give me some feedback. 
>

Hi Matthias,

I'm going to be starting on some work pretty soon which gives Helix 
Player / RealPlayer for Linux the ability to support basic functionality 
of alternative media engines, in the interests of making the player a 
little more "universal".

People have suggested to us in the past that we look at D-Bus [1] as a 
potential technology of interest here. The basic idea here is that one 
would write a media service "backend" and register it on the bus.

Applications would pass in an XEmbed socket (GtkSocket, 
QTXEmbedContainer) to the backend over D-Bus, and the media service 
would take care of doing the actual playback.

Clearly D-Bus is adding some overhead here, but it does offer a couple 
of advantages:

- Running the media engine out of process means that a media engine 
crash doesn't also crash the player. Important for us when dealing with 
3rd party engines on linux.
- I believe running the media engine out of process is also helpful for 
projects like SELinux in terms of locking down permissions on the media 
engine backend -- I'm not an expert here though.

I'm working on a doc of my own that talks a bit about my current train 
of thought here [2].

[1] http://www.freedesktop.org/Software/dbus
[2] https://player.helixcommunity.org/2004/developer/gtk/sods/ame.html

Anyway, as we're both working on similar things, it would be cool if we 
could collaborate here in some way.

I think the goals of kdemm are a bit more broader than what I was 
thinking about on my side, in particular:

(on Section 2.1, Actors)

One actor worth considering is a system integrator -- ie, someone at a 
linux distribution who says "we're supporting (polypaudio/jack/alsa 
asym/usound/anything but esound), our multimedia applications on kde 
will all work with sound server X out of the box".

I was thinking of leaving the configuring of media engines to 
distribution integrators & advanced users, punting on the creation of an 
easy admin-configurable unified media engine configuration interface for 
now.

(on change audio output volume)

    The user wants to change the volume of some program because it is
    too loud compared to the sound of another program.

I was thinking of leaving this unspecified in what I'm doing... If the 
user has a sound server installed that can do this, great.

(on domain constraints)

    It must be possible to run the desktop over the network, not only
    the GUI, but also audio output. If it is possible, the system should
    try to play the audio on the computer where the GUI is shown by default.

I was also planning to leave this unspecified, as something sound server 
dependant.

(on create reusable audio path)

In general, I wasn't planning on assuming a graph-based architecture in 
the underlying media engine, and in fact was going to punt on effects 
for now (like eq, reverb, equalizer).

I'd probably implement this down the road by creating a basic effects 
interface that actually has methods to configure cross fading, eq, 
reverb, etc. rather than doing pipleline manipulation. I think this is 
going to be tough to do in a cross-media engine way...

Is there any way that the work I'm doing could be useful to you guys?

-- 
Ryan Gammon
rgammon@real.com
Developer for Helix Player
https://player.helixcommunity.org

_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]