FAQ037

From the ALSA wiki

The FAQs have been reorganized. The new location of this question is FAQ#Which is the relationship between ALSA and sound daemons, like ARTS or Esound?

Which is the relationship between ALSA and sound daemons, like ARTS or Esound? Will it be possible in the future to replace ARTS and Esound by ALSA, so every program doesn't have to support different sound servers?

I've seen this confusing question many times in IRC channels so I'll try to give an answer. One part of ALSA is managing the sound devices. Either as module or compiled into the kernel. This means ALSA is really accessing and doing the real control of your soundcard. Look at /proc/asound. It's get confusing with the way ALSA programs are (supposed) to access the hardware. In the past (and unfortunately still) programs accessed a device in /dev directly to talk to the kernel. ALSA has an userland (outside the kernel) library used for accessing the kernel sound devices. This allows software mixing DmixPlugin without sound servers for example.

The relation between ALSA and the sound daemons is that the sound servers can access the sound through the ALSA library. In the (perfect) future all programs will use the ALSA library and will be able to replace the sound deamons. But even right now applications are developed for OSS. Note that in a perfect world sound daemons will not be needed in the first place. They are used for software mixing instead of the hardware mixing something soundcards are supposed to do (and cheap cards don't).

[There are updates in cvs to improve the OSS emulation. This should allow all the legacy OSS dameons to share the alsa sound devices.]