[long] sound-server history Re: [linux-audio-user] What's arts?

Robert Jonsson robert.jonsson at dataductus.se
Sun Sep 7 08:07:00 EDT 2003


Hi,

Sunday 07 September 2003 12:04 skrev Rick Taylor:
> G Cote <garyb at cotecorner.com> wrote:
> > Apparently, I'm running arts. Great. One more thing
> > I don't really understand.
> >
> > Now, I've been to arts-project.org and see that
> > it's the Analog Realtime Synth, blah blah blah.
>
>                             ^ It's a synth.
>
>  ...Like buzz or AudoMulch. You set up different modules that make noises
> ...then you pipe those through other modules that screw them up and then
> you make music with the whole mess.
>
> > Questions: do I need it to capture audio from
> > the sound card? Should I be trying to trouble-
> > shoot it? Or is it getting in the way of things?
> >
>  :} You might make music with it.

Though this is accurate, it's only half the story about aRts.

I think this requires a short introduction of sound in linux to give a better 
understanding to the subject at hand. 
Atleast the parts of it that I'm aware of and think I understand. Don't hold 
your breath...this will probably be longer than I intend to, relax and enjoy.

<Rewind ...10 years>
<Stop>
<Play x 10>
<theatrical beginning>In the beginning there was nothing.</>

Then there was a company, Open Sound System, with audio drivers for unix 
derivatives, I don't know if they targetted Linux in the beginning, but it 
was the first that was available in linux on a grander scale. They got a cut 
down version of their drivers included in the kernel, OssFree, these are the 
drivers accessed through /dev/dsp.
One problem with these drivers was that they where only for one user at the 
time. 
If you started e.g. XMMS and played some music and after a while some other 
app wanted to use the soundcard it had no choice but to wait for the current 
user to finish up. A very troublesome environment.

To solve this the concept of sound-servers was introduced, in the beginning 
the most spread sound-daemon was ESounD (Enlightment Sound Daemon), which 
worked rather good for it's design goals. But it got a lot of bad press for 
it's below par sound quality.
ESounD may still be the sound daemon used in Gnome (?), it was at one time 
anyway.

Other sound-servers where born, KDE started out with a sound-server that was 
even worse than ESounD, at some point they decided to use something else. 
They settled for ARTS, yes... the software synth... reasons being unknown to 
me, but ARTS is quite advanced, and developed in C++, it fit the KDE 
architecture rather well, SO BE IT. ARTS is from now on formostly a 
sound-server. The goals of producing a software synth lives on, but I think 
very little work is being directed towards that these days, maybe later on...

At some point along the way, during the sound-server development, ALSA was 
developed as a new sound-card architecture. ALSA, now the sound-driver 
formostly being used in Kernel2.6 will soon be what most distros use, as 
DRIVER.
But ALSA still doesn't remove the need for a separate sound-server. ARTS and 
other sound-servers will live on for this purpose. (There is a Mux plugin in 
ALSA that someday will make usable sound-server capability IN alsa, but I 
don't think this is reality yet, and I don't know if this is the right way to 
do it.)

It could also be noted that many newer consumer-grade sound-cards has built in 
mixing capability and can handle several apps accessing the card at once 
(E.g. SB-Live and relatives).

These days lots of apps have output plugins for ARTS and it has evolved into a 
very good sound-server. With one exception, real-time-ness, which is 
something that is deemed necessary for any professional audio app. 

Hence pure audio applications has almost always used the sound-card directly.
Using the sound-card directly is the way it is done with pro-audio in other 
operating systems also so we this was almost inevitable.

The story does however not end here, one can even argue it starts here. Some 
of the great brains of the Linux-Audio community came up with an alternative: 
Enter JACK, which is a major step in pro-audio sound-server technology. A 
sound-server with one major design goal, everything should be possible to be 
done in hard realtime.
As an exercise for interested reader, go to http://jackit.sf.net and find out 
more about JACK.

There has been and are other similar technologies around also, e.g. GStreamer 
which I know little about. The scope is getting broader for these and similar 
technologies, they are more oftenly called media-frameworks.

<Play x 1>
Ok... that is definately enough for now...

Regards,
Robert

<DISCLAIMER: 
This may all be wrong, came all from my memory (though I have <homer-simpson 
voice>footagraphic meemooriee</>), if so, please correct me by replying to 
the mail.>








More information about the Linux-audio-user mailing list