Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-amd64@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: Re: arts
Date: Sat, 09 Jul 2005 03:15:16 -0700
Luigi Pinna posted <200507090437.21664.mailing-gentoo@...>,
excerpted below,  on Sat, 09 Jul 2005 04:37:17 +0200:

> Sorry, I have a question:
> can you use arts without problems? If I use arts, it crashs often and
> freeze the computer...
> Usually I can't login in a session where one or two programs, that they
> use arts, must be open (a restored session). If I do that, the computer
> freeze immediately. Am I alone?
> I recompiled KDE without arts support now, but I have no system sound and
> kopete sound...

ARTS is working just fine, here, arts-3.4.1-r2 compiled with
gcc-4.0.1-pre20050607 I think it was.  The hardware is the onboard sound
on a Tyan s2885 dual Opteron board, AMD-8xxx chipset, meaning the intel8x0
ALSA driver.

Every once in awhile I have issues with it, and have to play with the
settings, switching artsd between the ALSA, OSS, and OSS-threaded driver
modules.  Very occasionally, something in the ARTS config will get
corrupted as well, and I'll end up having to delete all the arts temp
files (and the dcop temp files) and the like.  However, I eventually get
it all working again.

Note that everybody, including all the KDE devs that know anything about
it, considers ARTS a huge mess.  It has been barely maintained for some
time, the code is spaghetti code and difficult for anyone to do anything
with, there are quite a few untouched open bugs on it at KDE bugzilla, and
the original ARTS authors are no longer with KDE, and nobody else wants to
/touch/ it, let alone claim maintainership.  Yes, the code /is/ that bad. 
As well, the entire arts project suffered from overreach from the
beginning.  They tried to do to much in one thing, instead of taking the
traditional Unix approach of a bunch of small apps or modules, each doing
only one thing, but doing it WELL, so arts does quite a bit but none of it
WELL, and as mentioned, the code base is spaghetti to a point beyond

It's really a wonder they got it working on amd64 at all.

For all these reasons and more, KDE is moving off of arts.  However, for
compatibility reasons, it will remain with us thru the KDE 3.x series,
thus, will be around for the next minor release, KDE 3.5, which will
likely be out either late this year or next spring (a specific schedule
hasn't been set, yet).

3.5 is, however, supposed to be the last "tide-over" minor version of KDE
before KDE 4.0, which will be released a year to a year and a half from
now, so 2H2006.  KDE 4.0 will *NOT* have ARTS as a major component any
longer.  As a partial replacement for the KDE audio framework
functionality of ARTS, kdemm will appear.  The idea is a common API
framework that all KDE (and others, if they wish)  programs can call,
replacing that functionality within ARTS.  On the other end, the
driver/device end, it will have a plugin architecture, with "bridge"
plugins available to interface between the native platform sound drivers
and kdemm.  Thus, there'll be an ALSA plugin for modern Linux, an OSS
plugin for older Linux kernels and the BSDs, as well as the proprietary
OSS drivers, likely an esd plugin to interface with other desktop
environments, likely another plugin to interface with the just now
formulating sound project, etc.  The sound daemon software
audio stream merging aspect of arts, however, will NOT be directly
replaced, since many sound hardware devices and their drivers (alsa and
others) manage that in hardware.  For those without hardware stream
merging available, ALSA (and presumably OSS and others as well) provides
its own solution, so kdemm doesn't need to do so.

What's /really/ interesting about the kdemm infrastructure, however, is
just what it implies about adaptability to other platforms.  Keep in mind
that Trolltech has made a GPLed Qt4 library available for MSWormOS for the
first time, and aspects of the KDE community are targeting an MSWormOS
port of KDE-4 as well.  Because of the plugin architecture, kdemm will be
compilable with few if any changes for MSWormOS, only needing a driver
plugin very parallel to the one it uses for ALSA, to interface directly
with the MSWormOS native sound system as well!  Imagine, just as one can
run OOo or Firefox on MSWormOS or Linux or OSX or whatever, so KDE, with
version 4, is intended to be cross-platform.  Get folks used to the KDE
environment on MSWormOS, and a year or two later, it'll be much easier to
switch out the implementing platform from underneath it, and have them
running freedomware Linux, rather than proprietaryware, the opposite of
freedomware, MSWormOS!

Anyway, the bad news is that issues with ARTS aren't uncommon, and they'll
continue if not get worse for another year or so, as ARTS continues to get
the bare minimum of maintenance.  The good news is, with the release of
KDE4, anticipated sometime in the latter half of 2006, so a year to a year
and a half out, we won't have to worry about ARTS headaches any longer!

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in

gentoo-amd64@g.o mailing list

-- Benny Pedersen
Re: Re: arts
-- Peter Humphrey
Re: Re: arts
-- Alexey Maslennikov
Re: Re: arts
-- Luigi Pinna
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: arts
Next by thread:
Re: Re: arts
Previous by date:
Re: Re: arts
Next by date:
Re: arts

Updated Jun 17, 2009

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.