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. So arts lets multiple apps send audio to the sound card? Rather than write directly to /dev/dsp, they presumably send data through arts. What about the reverse direction? I guess I'd need a record app that reads from arts rather than /dev/dsp? 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. Thanks all. - gary --- Robert Jonsson <robert.jonsson@xxxxxxxxxxxxx> wrote: > 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.> > > > > > ===== -- Gary Cote gary@xxxxxxxxxxxxxx
