[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-multimedia
Subject: aRts as KDE2.0 audio server
From: Stefan Westerfeld <stefan () space ! twc ! de>
Date: 1999-09-05 9:49:42
[Download RAW message or body]
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 *-
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic