Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Re: arts
Date: Sat, 09 Jul 2005 10:18:08
In Reply to: Re: [gentoo-amd64] Re: arts by Luigi Pinna
Luigi Pinna posted <200507090437.21664.mailing-gentoo@××××××××××××.com>,
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 recovery. 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