[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: aRts as KDE2.0 audio server
From:       Stephan Kulow <coolo () caldera ! de>
Date:       1999-09-05 15:40:41
[Download RAW message or body]

Stefan Westerfeld wrote:
> 
>    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
Hey - little future kid! :)

Greetings, Stephan

> 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.
As long as they're not incompatible - who cares? But you should
introduce
new major releases only with KDE releases I guess.
> 
> - 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.
Installing suid root is no solution at all! We want to get rid of them,
not
adding even more. And not even some that are meant to be an essential
part
of the desktop.
I mean, who needs realtime priority for playing "you've got new mail"?
Noone.

To admit it, I would rather go with esd than with this big app, that is
more
meant for real multimedia than for an audio server ;(
If you can get together with the GNOMies and find a common standard that
may
be bigger and flexible - that's fine with me. But not for a KDE only
version.

Another idea: Perhaps we can define a layer app that redirects
application
requests to whatever sound daemon runs? If a user wants your app (sorry,
your typing is confusing) - he should be able to do so. If he runs GNOME
and only some KDE apps - GNOME's sound server should be fine too. OK, if
you say it's impossible - it is. But if it's reachable, I would see this
as ideal goal.


Greetings, Stephan

-- 
KDEDIR is dead, long lives KDEDIRS - the winner takes it all

[prev in list] [next in list] [prev in thread] [next in thread]