As main author of aRts, having after some time finally come to the conclusion that I won't continue to work on the project, I think its better to announce this publically than to walk away silently. Thus, whoever wishes to carry on work or rely on the code will also have an idea on the reasons why I no longer work on it. In general I hope that this contribution to the free software community has been beneficial, and might continue to be so, to those who wish to use it as a whole or its parts.
Two years ago, I became really distracted by real life issues, so that I was unable to find time and patience to work on the code at all for quite some time. Now, that I again have the time and patience to work on stuff, I find myself no longer sharing quite some of the basic assumptions that led to the design and way of the project, so its probably better not to continue - as Richard Stallman said at some point: "if you're not happily working on your free software project, its unlikely that you will produce great software, and then its better not to work on it" (I quote this from memory, so maybe the wording is not exact).
using communicating processes is a good way to handle concurrency
It is a very UNIXish way of thinking that concurrent threads of execution should be implemented as multiple processes; in fact, you probably use things like a seperate X11 server, apache spawns seperate web server processes, and pipes are used for scripts, where each processing step consists of a seperate process. GNOME, as far as I know, goes the same way with embedded bonobo components; everything is a seperate process.
When I started coding aRts, threading was much less widely used, and much less portable (or it seemed to me that way), and even today, significant improvements are made to the kernel and the glibc under Linux to handle threading in an efficient way, whereas processes - somehow - always worked.
In theory, threading can be replaced by seperate processes, in practice the aRts design hasn't benefitted too much from this. By making objects live transparently in seperate processes, much of the usual development process had to be reinvented to make it work easily. MCOP (the special purpose communication layer written for aRts) is largely a new way of thinking, similar to CORBA; with distributed reference counting, and messages that get passed for each method call being the consequences.
Besides that people are not used to it and do not understand it, it also makes code harder to debug, and it is harder to follow whats going on. And you get really hard to maintain code if you try to write your program in a way that artsd may crash at any point (noatun for instance tries to do this); its like trying to write a program where half of its objects may disappear suddenly at run time.
More so, putting all RT stuff into one process and all non-RT stuff (such as the GUI) in seperate processes did not work. Within the aRts process, there are still blocking calls that need to be made (such as reading a file from NFS). So, even though the RT stuff was supposedly seperated by the process abstraction, threads had to be introduced; and the framework (which needed to be kept relatively static, as we'll see below), makes development with two kinds of concurrency mixed not so easy.
handling audio mixing in the aRts process can suit everyone
An assumption underlying the design has been, that to achieve low latency when mixing seperate audio streams, it will be better not to do context switches. Thus, it will be most elegant to put all audio processing parts into one process only: the aRts server process.
While this sounds good in theory (and a dependancy on a predictable low latency scheduler, which is required for instance by JACK, is avoided), in practice this means that all application developers need to use this process for their audio processing tasks; otherwise, the whole idea won't work.
However, it turned out that some people don't want a sound server at all: there are multiple reasons for this; for instance, in some cases the hardware will do the mixing for you. Sometimes the application developer will be using an environment for developing that isn't really supported to run inside the aRts process (such as doing audio processing in some language that is not C++). Sometimes the hardware resources will not be sufficient for running aRts (aRts for instance internally requires float processing which is a problem on embedded devices).
Also, some specialized sound mixing solutions such as JACK (for hard RT) and the ALSA mixer seemed to be more useful for some reasons in some contexts. Thus, one of the basic premises - that centralizing all mixing inside the aRts process would be sufficient, doesn't really hold.
tying development to KDE is an advantage
For some time now, the development cycle of aRts was largely tied to KDE. I did argue for this, as tight integration will allow developers within the KDE source tree to innovate in aRts, and use the resulting innovations in a set of shared applications; thus signal processing code needs to be written only once.
But tying that "toolkit for audio" to KDE has also made using it outside the KDE context really rare, despite technically possible. Besides there has been the problem that the KDE binary compatibility requirements have been strict; thus, not being able to throw away and rewrite parts of aRts, the project has remained much the same as the initial design.
Of course, the fact that the aRts IDL compiler makes all methods virtual hasn't exactly helped. Because introducing a new method or attribute in a basic interface was impossible, new interfaces were added. So aRts has hierarchies like: Arts::SimpleSoundServer -> Arts::SoundServer -> Arts::SoundServerV2. This doesn't exactly help innovation.
Strictly speaking, doing interface renaming is correct and useful for maintaining backward compatibility; however it makes it extremely hard to evolve software, which is required if you don't really know what the perfect solution will be from start.
providing a unified solution for sound server, media framework and synthesis is desirable
In fact, there is an overlap between these domains. All require signal processing, and all require flow between data blocks with inputs and outputs. So the idea was to build a solution for the needs of all domains.
However, development has shown that the requirements by the different domains are also different. While a media framework needs to care about both, audio and video, synthesis only needs to care about audio. While a media framework and a soundserver have only moderate RT requirements, a synthesis software has extreme RT and low latency requirements.
Thus the seperate domains of aRts were somewhat struggeling, and it was hard to make things go smoothly in all areas. Besides, trying to solve all three problems at once requires much more coding resources and coding time than only solving one. Thus, while it may be possible with a team of 20 developers to provide a satisfying solution in all areas, doing the same hasn't been so easy with much less man power.
In fact, aRts can't claim to be great in video processing (I have never much liked the idea of introducing it half-heartedly, as it has been done at some point, because media players such as noatun needed it), there is significant room for improvement in all areas, with no end being seen.
a unified platform will lead to collaboration in development
While people have been working together, it has happened much less to the degree that I hoped for; in fact, everyone writing a media player or some other software was of course interested in making their own software work as well as possible, rather than working on a shared base; and thus, not much innovation has gone into aRts itself, where some innovation has gone in the frontends.
There is a specialized effect stack for noatun, for some shortcomings were found in Arts::StereoEffectStack, but it hasn't been backfolded. Of course, part of the problem is that with the design of aRts (IDL, plain C++, no Qt, extreme binary compatibility restrictions...), it has been much harder to work on "the shared base" than on the applications.
not using Qt as base for software development is a desirable design goal
"Not using Qt" as a design philosophy followed directly from the discussed goal that aRts should have been a shared base for lots of developers; even those outside KDE, which - at times with religious conviction - refused to work on software that used Qt. Thus, aRts was written in plain C++.
However, this has had two consequences. One was that the wheel had to be reinvented. Libraries like glib or Qt already provide for lots of standard things a developer needs (object model, threads, main loop). And thus, once you learned how to use them, they are very convenient to work with.
Arts reinvented everything from scratch, providing solutions at times less elegant, less sophisticated, and mostly non-standard, too. This made it hard for developers to contribute or adapt software to aRts. If they were working with Qt, they probably were not able to understand how to get anything done with aRts in the first place, being confronted with STL, IDL, a foreign object model and other aRts-isms. If they were working on a Gtk application, even C++ was a problem of its own; and the fact that aRts was tightly tied to KDE, at least in perception didn't exactly help either.
Thanks for doing it, its quite helpful if not everybody just says "great software". In fact, there also has been some criticism from users and developers. I think its always this way when struggeling for the right thing to do, there are arguments for doing it this way or the other. I wouldn't even say that aRts has no shining aspects of its design; while this text may not really emphasize the strengths it has, I still think it does quite some things quite well. Its just that I find other ideas more promising to work on right now.
Personally, I will continue to work on free software, as time permits; some of the ideas I have developed while working on aRts will go into BEAST - a pure music synthesis software - in fact, you'll find much of the ease of defining plugins with an IDL based system in BEAST already (I put some work in the idl compiler), and the first aRts plugins have been ported, I am working on fresh synthesis plugins for it.
BEAST has also much less the problem that it tries to solve lots of issues at once; it does music synthesis, and only this; which allowed Tim Janik (the main developer) to already come up with an impressive GUI, compared to what aRts has, in much the same time frame I spent on working on aRts. As it seems a bit inconsequent to switch from KDE to Gtk based development to some people, I can help to provide what needs to be provided to develop applications based on the BEAST synthesis core - BSE - with Qt, if somebody is interested in working on a Qt GUI. I have put some work into plain C++ language bindings already.
However, the sound server and media framework question I will have to leave to others; as for the first one, I'd recommend a pure sound server, which is not too heavy, so that it may possibly become a standard shared by GNOME and KDE; MAS or Polypaudio come to my mind, but there may be other interesting candidates.
As for the second one, I think a media framework like GStreamer might be useful, which can handle both, audio and video, and should be bindable to Qt, thanks to the object technology, whereas for GNOME it is already a native approach. There may be other candidates here, too.
In either case, I don't think desktop specific solutions make sense; whatever gets used should be shared. Just imagine how unconvenient it would be if KDE and GNOME would use different, incompatible X servers.
For a media framework, for some time it might be useful to support multiple solutions or leave applications the choice; for a sound server - as discussed above a "one size fits all" approach may not even be useful. Rather, it might be possible to standarize on a common API to output sound (for most applications, that is; music applications and other sound intensive code may still need to access the low level APIs directly), and then leave the choice of the sound server (or no sound server, as in the case of hardware mixing or kernel mixing) to the user.
I have once designed CSL together with Tim Janik to become such a common API for sound, and we wrote a paper about it, but we currently don't actively work on it; however, I have been pointed to PortAudio, which might be another candidate for a common API for sound, and ALSA, which although not currently portable to other UNIXes (and thus, uninteresting for a portable desktop such as KDE) may be portable in the future. Again, there may be other candidates.
As for the time frame to migrate to something other than aRts, KDE3 is still bound to support aRts by binary compatibility restictions; KDE4 might make fresh choices. However, as the philosophy for KDE has always been: "those who write the code make the design decisions", I will leave the choices KDE makes to others.
Of course, there is some kind of gap now, which means
I know that some other people involved one way or the other with KDE have already started filling the gap, during the time I didn't work too much on aRts, and I hope everything will continue to go well.
Stefan Westerfeld, 2.12.2004
links by topic