A sound server is a process
that mediates sound
related operations and data between a an application and hardware
sound subsystem.
Its main purposes are mixing of multiple sound streams and other
transformations of the sound data.
By far the most common use is however simple mixing, as the sound
server acts as the only process with access to the hardware sound
subsystem, and every other process connects to it to read or write
sound data.
The function of a sound server can also be performed by a sound
library where processes that want access to the hard sound
subsystems share the library code and some shared data segment with
interlocking, and this is how the
ALSA library
works, but by far the most common design for a sound server is as a
d&aeling;mon
process to or from which sound data is
spooled
in a way very similar to a print server like
CUPS.
The most common sound servers are or have been:
- aRts
which was used mostly for the
KDE
up to version 3.
- EsoundD
>ESounD
which was used mostly for GNOME up to version 2.
- JACK
which is mostly used for relatively sophisticated sound processing
in audio oriented Linux distributions.
- PulseAudio
once called PolypAudio.
In practice only JACK and PulseAudio are in common
use.
SOme of the sound servers above can be used as network sound
severs as they can accept remote connections from other hosts,
allowing sound applications to use sound system hardware on another
computer, an there have been sound servers designed principally to
allow this, for example:
None of these is in common use.
However the main purpose of most sound servers remains the sharing
and mixing of a hardware sound system among many processes on the same
node, and secondarily transforming that sound as it is streamed.
PulseAudio is a somewhat particular sound server because the single
most important aspect of its design is that it is meant to share a
sound system only among processes belonging to one user.
Because of this it must use some other way to share the sound
hardware among different users, and this is usually the ALSA library with its dmix plugin.
Also, since many applications have been written to use directly the
ALSA library, PulseAudo is usually invoked indirectly via an ALSA
library plugin,
pcm.pulse { type pulse; }
ctl.pulse { type pulse; }
pcm.!default { type pulse; }
ctl.!default { type pulse; }
Therefore the typical setup is that the applications running for a
user are linked with the ALSA library, and uses it to interact with
the PulseAudo dæmon for the user, and the dæmon processes
the sound data and uses the ALSA library to share the hardware sound
system with other PulseAudio processes.
There are then
