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

List:       kde-multimedia
Subject:    Re: Multimedia SIG results
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       1999-10-26 0:49:18
[Download RAW message or body]

   Hi!

> This is an exact copy from the paper we wrote, isn't it ? :-)
This was the purpose, yes ;)

> Btw, I would like to note something. 
> IMHO, we are diverging from the rest of KDE too much.
> It seems that finally aRts will be the _only_ app in
> KDE 2.0 that will use mico.
> If we have a look at the size of that library,
> we will find that _every_ user that wants to have sound
> will have to load a 6 Mb lib just for aRts even if
> all the apps they use only want to use a beep();

It would be something like 4 megs or less, but the problem is that
CORBA makes no sense at all if you are the only one using it.

> Adding that to the size of aRts itself and whatever more,
> how many non-shared Kb. will take just the audio server ?
> I suppose at least 8 Mb (6Mb from mico, 1 Mb for static
> KApplication, etc. and 1 Mb for internal usage). That's
> tooo much. I haven't done any test for this, so I may
> be wrong (and I hope).

Needs no KApplication for just audio serving.

> Would it be possible to do as the rest of KDE ?
> I mean, moving from mico to dcop/kidl and all that ?
> Even if these new libs takes also 6Mb of memory, at least
> that will be shared among every app.
> 
> Please Steffen, think of it very seriously. The rest of
         ^^^^^^^ => it's Stefan (the revenge for misspelling you once? ;)
> KDE is dropping mico because it's bloated and takes too much
> room. If we continue using it, we will break their idea,
> as we will keep it on memory.

I am thinking seriously...

The clean solution, as I see it, would be rewriting aRts to rely only on
the Unix API and the C++ standard (that is STL).

That way, it would be portable enough to become a standard like esd.

The TODO point "transfer layer needs to be rewritten" could translate to
"aRts should come with an own IPC mechanism, which is commited to deliver
high performance, multimedia transfer, QoS, etc.". That would mean not
using DCOP, but - to have a name - ACOP, and try to build highspeed
multimedia IPC suitable for streaming videos around, sending midi events
in time, etc.

The components of a so rewritten aRts would be:

- an IDL standard (aidl), which allows definitions like

interface Add {
	 in audio stream signal1, signal2;
	out audio stream result;
};

interface StereoSoftSynth {
	in midi event stream midi1;
	out audio stream left, right;
};

// and something along the lines of (which is copypasted from the SIG
// protocol, and is intended to offer KMedia functionality):

struct poTime {
    long ms, seconds; // -1 if undefined
    float custom;     // some custom time unit (changed to float, is that ok?)
                      // -1 if undefined
    string customUnit; // for instance for a tracker "pattern"
};                                                                              

interface PlayObject {
    attribute string description;
    attribute poTime currentTime;
    readonly attribute poTime overallTime;
    attribute poCapabilities capabilities;
    readonly attribute string mediaName;
    readonly attribute poState state;

 
    void play();
    void seek(in poTime newTime); // could be handled by setting currentTime
    void pause();
};                                                                              

// and an mp3 player could then be very cleanly defined as

interface AudioProducer {
	out audio stream left,right;
};

plugin MP3PlayObject implements PlayObject, AudioProducer;

- a language mapping, which maps these to implementable C++ plugins
  (optionally, people could implement stuff in other languages)
- a scheduler, which evaluates flow graphs and takes care of all the
  invocations and streaming between the plugins, even if they are
  distributed
- a transfer service, which takes care of transmitting stuff between
  differend processes/hosts
- for interoperability, the best thing would be a DCOP proxy, which injects
  DCOP requests into ACOP (and perhaps vice versa).
- a CORBA proxy could optionally be written
- a format to describe the idl interface in machine readable form (XML?)
- a format to describe flow graphs = object composition (XML?)
- a flow graph editor, which operates on the interfaces
- a dynamic loader, which cares for deep modularization, compared to old aRts

That's just a snapshot of what I'm thinking right now. The problem is, that
doing that will almost certainly break our "milestone listing", and I am not
sure if we could come up with something that works properly until KDE2.

Why ACOP?

I think one thing that many people didn't like about aRts was, that it wasn't
self contained. You couldn't just to -larts and have a flow system (which
should be possible with the new approach, which would mean: waveeditors etc.
are covered as well). You needed to care that mico was there as well, and
installed with disable-ministl etc.

When depending on DCOP, the same thing would happen. People would need to
link to -ldcop* -lqt -lX11 -lXext and have a dcopserver running just to
run aRts. (This is only an issue if we're assuming that somebody out there
might want to use aRts but not KDE, which would be the case if it could
replace esd in the long run).

Also, we need extensive support for something like midi event streams,
video frame streams, audio streams, etc. already in the protocol and
interface defs to have a clean concept. With the old CORBA based approach,
all that didn't work, and with DCOP it wouldn't either.

And: aRts can't change IPC paradigms once per year. So probably it's
best to have the things there where they are needed, and to care that
they exactly fit to what you need to do with a multimedia subsystem. I
also have seen that using different IPC paradigms in one program (such
as the hacked in TCP server for aRts) is really a mess, so aRts should
only use ACOP, and everything else should be done via proxying to the
protocol that is needed.

So aRts would come with a lightweight multimedia object request broker,
though that wouldn't relate to CORBA at all.

   Cu... Stefan

PS: Perhaps you were right when asking me wether a rewrite wouldn't be
better... ;)
PPS: Sorry about the unordered form of text - as you see, I am still
thinking, and before I don't have implemented at least an aidl prototype,
or something similar, I wouldn't say that the new concept can be officially
announced/decided to be The-Right-Thing-To-Do(tm).
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

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