[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-multimedia
Subject: Re: aRts as KDE2.0 audio server
From: Cristian Tibirna <ctibirna () total ! net>
Date: 1999-09-06 2:49:14
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic