Ross S. W. Walker wrote:
> Ignacio Vazquez-Abrams wrote:
> > On Tue, 2008-03-11 at 11:59 -0400, Ross S. W. Walker wrote:
> > > I have been working a while trying to get a big picture of how Linux
> > > handles sound processing and after much work I have put together this
> > > little representation of what I have learned.
> > >
> > > Please send me any additional comments or components that I may have
> > > missed.
> >
> > Some corrections (PulseAudio contains an ALSA module that can redirect
> > audio back into PA):
>
> ALSA provides an ALSA driver in it's plugins to send audio to a
> PulseAudio server, so that part is pure ALSA. I mean sure it
> uses PulseAudio's protocol to send over the network, but as far
> as ALSA is concerned it's just another ALSA kernel driver for
> communicating with sound hardare. The PulseAudio server by
> itself is of course a pure sound server.
>
> Having said that, I don't believe that the ALSA driver for
> PulseAudio counts as yet another interface.
>
> AOSS is merely a shim for the builtin OSS Compatibility API to
> force older OSS apps to use the API properly, because of that I
> count AOSS as part of the OSS Compatibility API.
>
> Also sound servers can and do use third party API products such
> as GStreamer. Often GStreamer provides those plugins on behalf
> of the sound server (cause no one else wants to), but the
> plugin is still part of the sound server and as far as the sound
> server is concerned it is just sending audio directly to the
> hardware API. GStreamer/Phonon also have plugins for
> communicating with sound servers as well as HW APIs such as
> ALSA or OSS. When diagramming these third party APIs things
> can ugly pretty darn fast.
>
> Thanks for the additional examples, but I still stand by my
> original diagram. Maybe someone can take each part of the
> diagram, zoom in on it and show which apps/apis/modules from
> which project interface between each other and in which
> direction.
>
>
> > > Linux Sound Architecture
> > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > > X Linux Sound Applications X
> > > X X
> > > X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > > X X Third-Party APIs X X
> > > X X GStreamer/Phonon/ X X
> > > X X xine-lib X X
> > > X X X X
> > > X X XXXXXXXXXX X
> > > X X X Sound Servers X
> > > X X X ESD/aRts/NAS/JACK X
> > > X X X X
> > > X X X X
> > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > > X X OSS Compat API X
> > > X ALSA API XXXXXXXXXXXXXXXXXXXXXX
> > > X X
> > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > > X Linux Kernel (ALSA driver) X
> > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > > X Sound Hardware X
> > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> >
> > Yes, audio on Linux is a mess.
>
> This I do agree with though!
One thing I didn't think of initially that Ignacio reminded
me of in his diagram is the Ying/Yang relationship that
the third party sound APIs and the sound servers have. What
I mean is that sound servers have plugins for communicating
with hardware APIs, third party APIs and other sound servers.
While third party APIs have plugins for communicating with
hardware APIs, sound servers and other third party APIs.
I modified the image to see if it can be graphically
portrayed. It's better, but if a picture is worth a thousand
words, then one needs ten thousand words to properly
explain this one.
-Ross
______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
