Linux sound

Sound / Audio in Linux seems to be a wild jungle. This page is an attempt to summarize the situation.

References

• http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html
  A summary of the situation back in the year 2007.
• http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html
  Same but updated to situation in 2009. A well of information!
• http://4front-tech.com/hannublog/?p=5
  Blog post explaining why closed source OSS is better than Alsa (back in 2007).
• http://blogs.adobe.com/penguinswf/2007/05/welcome_to_the_jungle.html
  A dependency graph between all sound systems, frameworks, libraries, etc in Linux (direct link)

Landscape

Here a summary of usual names we find in the Linux sound jungle along with their meaning/roles.

The sound systems (the real stuff that interface with the sound card. Today no apps should use these API directly but instead use one of the simple wrapper instead):

• OSS v3 — Open Sound System
  • The original sound system on Linux, derived from the Sound Blaster driver API.
  • The main limitation of OSS is that there was no software mixer (mixing was done by the soundcard) and so if your sound card did not support mixing in HW, then only one application could generate sounds.
  • Closed Source
• OSS v4
  • Open source again
  • Full support of mixing
  • Better latency (done in kernel)
• ALSA — Advanced Linux Sound Architecture
  • A new sound system for Linux, including new set of API, kernel modules, etc.
  • Support SW mixing
  • Created after OSS went closed source
  • Provide an OSS emulation layer for applications that still requires OSS
  • Many advantages but many drawback as well (like OSS emulation does not support mixing, requires many additional lib like alsa-lib or jack)

The wrapper libraries (to support any sound back-end API, i.e. OSS/ALSA):

• SDL — Simple DirectMedia Layer
  • Wrapper around OSS, aRTS and ESD.
  • To allow running at the same applications that uses OSS, aRTS or ESD.
• OpenAL
• libao

The sound servers (Add mixing, considered useless today and adds lot of latency on top of the OSS/ALSA back-end):

• aRTS — Analog Real Time Synthesizer
  • Old sound system for KDE environment
  • Main goal was to cope with lack of SW mixing layer in OSS.
• ESD — Enlightened Sound Daemon
  • Old sound system For Gnome/GTK environment
  • Main goal was to cope with lack of SW mixing layer in OSS.

ALSA / OSS

ALSA

3 components:

• Drivers in the kernel
• Sound developer API
• Sound mixing component

Pros:

• Optional sound mixing outside the kernel
• Alsa support OSS v3 emulation

Cons:

• OSS v3 emulation has no mixing outside kernel (i.e. no mixing for old or other Unix'es apps when HW does not support mixing)
• Linux only (i.e. SW written to support other Unix'es will likely be written for OSS
• API too hard to work with

OSS

Now at version 4.

Pros:

• Sound mixing always supported
• Mixing in the kernel (so no latency issues)

Cons:

• Very bad ALSA emulation (but ALSA sound developer API can output to OSS directly, hence providing perfect ALSA compatibility).

Summary

• Both sound systems can output to either ALSA / OSS kernel back-ends.
• OSS back-end always has good sound, except when using OpenAL->ALSA to output to it.
• ALSA generally sounds better when using the OSS API, and has lower latency (generally because that avoids any sound mixing as per an earlier diagram).
• OSS related technology is generally the way to go for best sound.
• No application should use these APIs directly, but should use one of the light library wrapper instead.