Fwd: Re: aRts vs JACK
stefan at space.twc.de
Sat Feb 22 21:00:51 GMT 2003
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
- 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.
-* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
More information about the kde-multimedia