[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:       Cristian Tibirna <ctibirna () total ! net>
Date:       1999-09-06 2:50:42
[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]