Notes about Linux sound servers

Updated: 2013-01-04
Created: 20133-01-04

Sound server introduction (130104)

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:

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 (130107)

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