From kde-core-devel Sun Sep 05 09:50:11 1999 From: Stefan Westerfeld Date: Sun, 05 Sep 1999 09:50:11 +0000 To: kde-core-devel Subject: aRts as KDE2.0 audio server X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93652501107454 Hi! I talked a lot with Christian Esken and other about KDE & Multimedia at the Linuxcongress'99. Later, I posted some thoughts on the KDE lists about K2Multimedia stuff. About four weeks ago, Christian Esken asked me whether aRts could replace KAudioServer2 in KDE2.0. He said he has lots of stuff to do, and little time to spend upon completing his KAudioServer2. Sure aRts can replace it, I just need to make a few tests, I answered. Well, the tests are done now, the results are fine. With the latest aRts, you can do something like mpg123 -s some.mp3 | artscat -t mp3 -d "my mpeg" and it will replay it. You can do that with six mp3s at the same time, too. It doesn't sound that nice listening to all of them at once ;) - but it works. Here are some arguments I collected for and against the usage of aRts in KDE2.0. PROs ==== + aRts core (not the GUI of course) doesn't depend on Qt => That will make it possible for other desktops/apps to use aRts as audio server (Gnome for instance?), even if they are not into Qt. This may be hypothetical, but its nice to know that that door isn't closed. + aRts can directly compete with other desktop multimedia systems => Microsoft for instance puts a lot of effort into multimedia, such as DirectShow/DirectSound and the upcoming DirectMusic stuff which will be in Win2k. BeOS as well has a nice multimedia API, and Apple provides its QuickTime stuff. And of course there is Gnome with their GMF. While I don't know many details about them, the idea is on all sides to provide easy multimedia application development and good interoperability with components. Arts can do that as well, making KDE2.0 a better place for multimedia developers. + aRts is very modular, extensible & CORBA based => Integrating a new wave form for instance is a matter of 20 lines of code. Integrating the audio server stuff was a matter of a few days. You don't get that with a monolithic approach... + aRts is there & stable => Arts is under development since nearly two years now. It works all the time. The flow system is well tested, and the realtime performance is fine. It's not some "here I have specs that you might want to read"-project, but something that is implemented and known to work. + I can and want to make it happen => My time is limited and my project to work on is aRts. Thus, after suggesting that we might want to use GMF for KDE2.0 I realized, that while it might be a good idea, it wouldn't be the thing to work on for me, as I can't split myself between aRts and GMF. On the other hand, working on having aRts in KDE2.0 should be possible from the time and motivation I have. POSSIBILITIES ============= * later integration with OpenParts/KOM technology => Integration with KOM (and possible OpenParts+other KOffice technlogogy like KScript) is possible since aRts is designed for server operation. That would, if completed, give great possibilities to have a proper component integration into all KDE2.0 apps. Thus aRts could make OpenParts/KOM not only suitable for boring office apps, but for games, sequencers,... * it could be extended towards other multimedia services (video/midi) => Currently aRts is designed to do mainly audio. Midi is there, but as a kind of necessary problem to solve for a software synthesizer, rather than as proper implemeted concept. However aRts could be extended to handle video and midi as well, with nice aRts modules, thus giving us the ability to handle all media with one (filter graph supporting) concept. CONS ==== - it would be a bad idea to couple the release cycles of aRts and KDE => This is a technical problem which should be solvable: I don't want that during making aRts the KDE2 audio server, people will only be able to install a new aRts version with every KDE release, that is every year or so. The aRts releases are currently every one or two months, and that should stay like that. - aRts is incompatible with other solutions of the problem => There are a lot of solutions for the same problem around, for instance esd, GMF, NAS, KAudioServer1/2, and perhaps some ALSA concepts. Arts is naturally incompatible with all of them. - it wasn't designed to be an audio server => aRts stands for "analog realtime synthesizer". It is designed to be just that. Accidentially, it happens to be able to solve the problems of an audio server easily, due to its flexibility. But of course it contains lots of code and infrastructure for synthesis, midi handling, etc. - it is quite a bit larger that the current solution => Compare aRts stefan@orion:~/src/kde/kmusic/ksynth> wc `find . -name \*.cc; find . -name \*.cpp; find . -name \*.h`|tail -1 23818 61614 570556 total with the current KAudioServer1 solution (KAudioServer2 is similar) stefan@orion:~/src/kde/kdelibs/mediatool> wc `find . -name \*.cc; find . -name \*.cpp; find . -name \*.h`|tail -1 766 2846 21718 total stefan@orion:~/src/kde/kdebase/kaudio> ~/linc wc `find . -name \*.cc; find . -name \*.cpp; find . -name \*.h`|tail -1 2944 10324 79839 total The output is lines words bytes, and is of course affected by GPL copyright banners in every file, comments and coding style. However, aRts is close in size to libkonq+konqueror. - it does require root rights for realtime operation => Currently, you are supposed to run aRts with realtime priority. There is a system call (sched_setscheduler) that ensures it gets the right priority (to avoid your mp3 to stop if you start netscape for instance), but it requires root rights. Arts can be installed suid root for that, and there may be a way to redesign some of its routines to run in non- realtimed mode as well. However, you'll get latency problems them, so installing suid root would be the best solution. - it uses more resources than "handoptimized" lean C solutions like esd => Arts is based heavily on CORBA and very modular. If you start a current release, a thousand CORBA objects are built. If you hit a key on your midi keyboard, thousands of lines of code decide what to build in memory, why and how, and then dynamically, small aRts modules are added and connected. While it is designed to be reasonable fast during all that, of course some other solutions like esd should be able to achieve higher performance, while of course being less flexible. I would like to hear all feedback you can give me. Especially, some kind of decision must be made whether it should be the KDE2.0 audio server, or what conditions must be met by aRts until it can be the KDE2.0 audio server. Until now, I haven't started Qt2 porting yet, because I am working actively on aRts as synthesizer application for KDE1 (which is very usable there, I guess). And if aRts shouldn't be in KDE2.0 core, it is probably a bad idea to make it KDE2/Qt2 compatible before anyone out there uses that for composing. Of course if the decision "aRts should be the KDE2.0 audio/multimedia server" is made, some issues still must be solved, but I am optimistic that aRts should be ready for release when KDE2.0 is. You might also want to look at: - The aRts homepage http://linux.twc.de/arts - The GMF whitepaper http://developer.gnome.org/doc/whitepapers/GMF/index.html - The aRts-0.3.3 documentation, section 11 (using aRts as generic audio server) ... I have put it there since the documentation on the aRts homepage is a little outdated http://space.twc.de/~stefan/arts-0.3.3-doc/index-11.html - CVS version of aRts (CVS module is kmusic, directory is ksynth by historical reasons) Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *-