Apparently, I'm running arts. Great. One more thing I don't really understand.

G Cote <garyb(a)cotecorner.com> wrote: ^ 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. :} You might make music with it.

From your post, and others by Guy, Rocco, and Rick,

Hi, Sunday 07 September 2003 12:04 skrev Rick Taylor: thing modules that make noises screw them up and then 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.>

garyb(a)cotecorner.com wrote:

Robert, Thanks for the back-story. It was more helpful than you could know. There are lots of very-detailed faqs out there, on numerous topics, but precious little that attempts to sum it all up. From your post, and others by Guy, Rocco, and Rick, I've been able to make some good progress. Knowing what components are required or optional for what I'm trying to do was a big help.

At any rate ... I disabled the arts server, and can now record from /dev/dsp. I'll have to determine based on experience whether I miss any of the features that arts provided.

There is an argument for not using a general-purpose sound server when making music. Anecdote: a few years back, there was a song that got quite a bit of radio airplay that featured somewhere in the middle the sound effect on Windows for 'you've got mail'. It used to annoy the hell out of people who listened to the radio while working on their computer, and the radio station I was listening to at the time got a few complaints.

Sorry - I can't remember the name of the track. The irritating sound effect was the most distinctive thing about it...

And to think - people walk around with one of these clamped to the side of their head, just a few millimetres away from their brain - a subtle and complex electrical system if ever there was one!

Hehe, I've been meaning to embed the GSM "I'm resyncing with the cell" noise into a track - that noise even seems to make its way into balanced cables.

>>>> "Daniel" == Daniel James &lt;daniel(a)mondodesigno.com&gt; writes: