| 1 |
Luigi Pinna posted <200507090437.21664.mailing-gentoo@××××××××××××.com>, |
| 2 |
excerpted below, on Sat, 09 Jul 2005 04:37:17 +0200: |
| 3 |
|
| 4 |
> Sorry, I have a question: |
| 5 |
> can you use arts without problems? If I use arts, it crashs often and |
| 6 |
> freeze the computer... |
| 7 |
> Usually I can't login in a session where one or two programs, that they |
| 8 |
> use arts, must be open (a restored session). If I do that, the computer |
| 9 |
> freeze immediately. Am I alone? |
| 10 |
> I recompiled KDE without arts support now, but I have no system sound and |
| 11 |
> kopete sound... |
| 12 |
|
| 13 |
ARTS is working just fine, here, arts-3.4.1-r2 compiled with |
| 14 |
gcc-4.0.1-pre20050607 I think it was. The hardware is the onboard sound |
| 15 |
on a Tyan s2885 dual Opteron board, AMD-8xxx chipset, meaning the intel8x0 |
| 16 |
ALSA driver. |
| 17 |
|
| 18 |
Every once in awhile I have issues with it, and have to play with the |
| 19 |
settings, switching artsd between the ALSA, OSS, and OSS-threaded driver |
| 20 |
modules. Very occasionally, something in the ARTS config will get |
| 21 |
corrupted as well, and I'll end up having to delete all the arts temp |
| 22 |
files (and the dcop temp files) and the like. However, I eventually get |
| 23 |
it all working again. |
| 24 |
|
| 25 |
Note that everybody, including all the KDE devs that know anything about |
| 26 |
it, considers ARTS a huge mess. It has been barely maintained for some |
| 27 |
time, the code is spaghetti code and difficult for anyone to do anything |
| 28 |
with, there are quite a few untouched open bugs on it at KDE bugzilla, and |
| 29 |
the original ARTS authors are no longer with KDE, and nobody else wants to |
| 30 |
/touch/ it, let alone claim maintainership. Yes, the code /is/ that bad. |
| 31 |
As well, the entire arts project suffered from overreach from the |
| 32 |
beginning. They tried to do to much in one thing, instead of taking the |
| 33 |
traditional Unix approach of a bunch of small apps or modules, each doing |
| 34 |
only one thing, but doing it WELL, so arts does quite a bit but none of it |
| 35 |
WELL, and as mentioned, the code base is spaghetti to a point beyond |
| 36 |
recovery. |
| 37 |
|
| 38 |
It's really a wonder they got it working on amd64 at all. |
| 39 |
|
| 40 |
For all these reasons and more, KDE is moving off of arts. However, for |
| 41 |
compatibility reasons, it will remain with us thru the KDE 3.x series, |
| 42 |
thus, will be around for the next minor release, KDE 3.5, which will |
| 43 |
likely be out either late this year or next spring (a specific schedule |
| 44 |
hasn't been set, yet). |
| 45 |
|
| 46 |
3.5 is, however, supposed to be the last "tide-over" minor version of KDE |
| 47 |
before KDE 4.0, which will be released a year to a year and a half from |
| 48 |
now, so 2H2006. KDE 4.0 will *NOT* have ARTS as a major component any |
| 49 |
longer. As a partial replacement for the KDE audio framework |
| 50 |
functionality of ARTS, kdemm will appear. The idea is a common API |
| 51 |
framework that all KDE (and others, if they wish) programs can call, |
| 52 |
replacing that functionality within ARTS. On the other end, the |
| 53 |
driver/device end, it will have a plugin architecture, with "bridge" |
| 54 |
plugins available to interface between the native platform sound drivers |
| 55 |
and kdemm. Thus, there'll be an ALSA plugin for modern Linux, an OSS |
| 56 |
plugin for older Linux kernels and the BSDs, as well as the proprietary |
| 57 |
OSS drivers, likely an esd plugin to interface with other desktop |
| 58 |
environments, likely another plugin to interface with the just now |
| 59 |
formulating freedesktop.org sound project, etc. The sound daemon software |
| 60 |
audio stream merging aspect of arts, however, will NOT be directly |
| 61 |
replaced, since many sound hardware devices and their drivers (alsa and |
| 62 |
others) manage that in hardware. For those without hardware stream |
| 63 |
merging available, ALSA (and presumably OSS and others as well) provides |
| 64 |
its own solution, so kdemm doesn't need to do so. |
| 65 |
|
| 66 |
What's /really/ interesting about the kdemm infrastructure, however, is |
| 67 |
just what it implies about adaptability to other platforms. Keep in mind |
| 68 |
that Trolltech has made a GPLed Qt4 library available for MSWormOS for the |
| 69 |
first time, and aspects of the KDE community are targeting an MSWormOS |
| 70 |
port of KDE-4 as well. Because of the plugin architecture, kdemm will be |
| 71 |
compilable with few if any changes for MSWormOS, only needing a driver |
| 72 |
plugin very parallel to the one it uses for ALSA, to interface directly |
| 73 |
with the MSWormOS native sound system as well! Imagine, just as one can |
| 74 |
run OOo or Firefox on MSWormOS or Linux or OSX or whatever, so KDE, with |
| 75 |
version 4, is intended to be cross-platform. Get folks used to the KDE |
| 76 |
environment on MSWormOS, and a year or two later, it'll be much easier to |
| 77 |
switch out the implementing platform from underneath it, and have them |
| 78 |
running freedomware Linux, rather than proprietaryware, the opposite of |
| 79 |
freedomware, MSWormOS! |
| 80 |
|
| 81 |
Anyway, the bad news is that issues with ARTS aren't uncommon, and they'll |
| 82 |
continue if not get worse for another year or so, as ARTS continues to get |
| 83 |
the bare minimum of maintenance. The good news is, with the release of |
| 84 |
KDE4, anticipated sometime in the latter half of 2006, so a year to a year |
| 85 |
and a half out, we won't have to worry about ARTS headaches any longer! |
| 86 |
|
| 87 |
-- |
| 88 |
Duncan - List replies preferred. No HTML msgs. |
| 89 |
"Every nonfree program has a lord, a master -- |
| 90 |
and if you use the program, he is your master." Richard Stallman in |
| 91 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 92 |
|
| 93 |
|
| 94 |
-- |
| 95 |
gentoo-amd64@g.o mailing list |
Archives