From kde-core-devel Mon Sep 06 02:50:42 1999 From: Cristian Tibirna Date: Mon, 06 Sep 1999 02:50:42 +0000 To: kde-core-devel Subject: Re: aRts as KDE2.0 audio server X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93658624216151 On Sun, 5 Sep 1999, Stefan Westerfeld wrote: > 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. AFAIK, one of the important goals of Christian was to implement network transparency in KAS2. > PROs > ==== > + 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 offers a library set? If so, this is excellent. In the light of what you say later, can a stable version of these libs be included in the kdelibs module and serve as a base for the kaudioserver while aRts will continue development on an own set of advancing libraries? > + 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... I acknowledge I don't get this. I would rather understand if you said that the modularity of aRts allows to *separate* not to *integrate* the audio server stuff. Anyhow, I will ask: would the modularity of aRts allow to separate part of its code and make a *small* audio server? (this is again in the light of what you say later, about the too large size of aRts compared with media2) > + 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. This is the strongest argument. > + 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. I don't know about GMF, but I experienced a bit with esd, and is quite demanding on the processor compared with the OpenSound drivers, which makes it slipping when I compile KDE2 :-) > 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. Excellent. Another real application of KDE's component technology. > > 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. See above. I think the better solution would be to adapt KDE's release scheduling to aRts' one :-) Releasing KDE too sparsely hurts us. > - 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. (Innocent request) could you please ellaborate? > - 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. See above. Could the synthesis part be separated and include the common part in the KDE libs? > - 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 Humble hint: use kdesdk/scripts/cxxmetrics to do the above. > - 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. This was already addressed by others. Can a user connect to a system-wide server started by the root? Then in highly media-centered installments of KDE, the admin can take care of this. In other kinds of shops (like at home or in non-media univ labs), either it doesn't count if the realtime operation isn't perfect or the user can however run thing as root at its own risk. > - 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. This is the worse problem we have to confront. This is also the reason for which I was asking about possibility to separate the server code. > 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. Hope the above helps. > 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. May I dare? in src/synthesizer/audioman_impl.cc#60-66 in CVS, socketIOEvent is not declared (should be in the header). In the aRts-3.3 source tarball this variable doesn't exist (an autodeleted ArtsIOEvent called ev is used). But the tarball doesn't want to compile for me because of missing socketbind.h or something. I added the socketIOEvent declaration in audioman_impl.h and all compiled well and functioned. Now I have to learn how to use it for the presentation I give next week :-)) > > - The GMF whitepaper > > http://developer.gnome.org/doc/whitepapers/GMF/index.html > Is there any code on this? I couldn't find any indices. Thanks Cristian