From kde-multimedia Tue Oct 26 00:49:18 1999 From: Stefan Westerfeld Date: Tue, 26 Oct 1999 00:49:18 +0000 To: kde-multimedia Subject: Re: Multimedia SIG results X-MARC-Message: https://marc.info/?l=kde-multimedia&m=94089917230654 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 *-