Fwd: Re: aRts vs JACK

[Stefan Westerfeld]

   Hi!

On Wed, Feb 19, 2003 at 10:31:27PM +0100, Roger Larsson wrote:
> Arnold Krille wrote:
> > On Wednesday 19 February 2003 18:06, Jozef Kosoru wrote:
> > > > > IMHO the only way to get rid of the artsd problems is forget about it.
> > > The correct solution (I know that it's just sci-fi) is to 'rm -rf arts'
> > > and write the necessary API for the KDE from the scratch. aRts was the
> > > KDE project mistake but now is a bit too late to make such a drastic
> > > rewrite.

Even _if_ anybody comes to the conclusion, that aRts is a serious mistake for
all of KDE (and I can understand some of the criticisms that aRts is constantly
exposed to), there are two things to keep in mind:

 * developing aRts has taken years, we're currently having 80000 LOC in aRts,
   thus, developing a replacement is a huge effort
 * KDE keeps binary compatibility, thus during the KDE3 cycle, we guarantee
   that aRts is still there

Thus I suggest taking an incremental path in any case.

 - if you favour GStreamer over aRts in the media framework sector, write a
   GStreamer PlayObject and thus show that noatun works better with it than
   with native aRts stuff

 - if you favour MAS over aRts, work alongside with those of us who want to
   make CSL a new abstraction layer for sound input/output, and thus enable
   KDE users to choose their sound server in the future

 - if you want apps to use JACK rather than aRts, make JACK aRts-aware or
   CSL-aware or the other way round

> > I know aRts isn't the best, but isn't your 'solution' a bit to drastic?
> > 
> 
> I do not think it is that drastic. Most usages of audio are contained in
> simple wrapper classes (KNotify, KAudioPlayer) and in a low number of
> programs. (most in kdemultimedia)
> It can be done if we want to...
> 
> But note that Arts handles video/network transparency/etc. too...

Thats the problem. Somewhere in the archives there should be a mail on a
proposed splitup of aRts. I identified three functionalities aRts currently
covers:

 - media framework
 - sound server
 - synthesis/music/effects stuff

Ideally, these could be seperated, and not bundled. But thats a lot of work,
and I suggest that we start small (by employing CSL and/or adding JACK support)
instead of trying to turn the world upside down in one day.

> > Instead of complaining you could help Stefan Westerfeld & co. to write 
> > something new...
> 
> The problem with arts as I see it is that it is quite difficult to get into,
> since it is quite advanced and have lots of features.
> 
> But also since there are code
>  that is not expected to be used (oggvorbis_artsplugin),
>  competing code (kdemultimedia/mpeglib/lib/oggvorbis
>                            and arts/flow/gsl/gslloader-oggvorbis)
> 
> So the question for those of you with crystal balls is "will Stefan & co. be
> able to keep ahead of the rest".
> 
> How to keep ahead:
> * a jack host(!) in artsd (a client should be implemented too...)

That would be great.

> * use of LADSPA plugins in addition to arts own.

I have some experimental LADSPA support code, and can tell anybody who wants
to complete it the necessary steps to be done.

> * update documentation

That would also be great. I am merely a human being with limited time and
resources (and I have other obligations than aRts), and the past has shown
that I can't

 - maintain www.arts-project.org
 - build a documentation system

alongside everything else I do. This is why the webpage is in a desolate state,
and it _needs fixing_ badly. The same is true for the documentation. I try
to compensate for this by answering all aRts related questions I get by
personal e-mail as good as I can, but of course, this is not a guarantee,
and much less a desirable state.

So...: please, anybody instead of complaining pick one item you consider the
most important, and do something.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-