7 Sep
2003
7 Sep
'03
11:38 a.m.
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(a)dataductus.se>
wrote:
Hi,
Sunday 07 September 2003 12:04 skrev Rick Taylor:
modules that make noises
=====
--
Gary Cote
gary(a)cotecorner.com
G Cote <garyb(a)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 ...then you pipe those through other modules that
screw them up and then
you make music with the whole mess.
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.>
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.