Hi, Sunday 07 September 2003 12:04 skrev Rick Taylor: > G Cote <garyb@xxxxxxxxxxxxxx> 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.>
