The current major Linux sound servers are Enlightened Sound Daemon (ESD or EsounD) for Gnome, analog Real time synthesizer (aRts) for KDE2/3, and Advanced Linux Sound Architecture (ALSA), which works everywhere. Network Audio System (NAS) is a client/server networked sound system for thin clients. For applications that require OSS, ALSA, ESD, and aRts all include an OSS emulator. JACK is a popular professional-level low-latency audio server. One thing these all have in common is they require ALSA to provide the audio hardware drivers.

ESD and aRts both support networked sound, and manage sound streams from multiple sources. ESD is hard-coded into Gnome, but thanks to the PulseAudio developers it should soon be divorced from Gnome, as a proper modular Linux application should be. aRts was designed from the beginning as an independent, portable audio framework. ALSA provides device drivers, multi-device management, basic mixing and recording, and works in any Linux environment, including the console.

ESD and aRts both perform both low-level and higher-level functions. Both interface between sound hardware and applications, and also encode and decode your various file and streaming audio formats. aRts does everything; ESD handles sound server duties, and GStreamer handles the encoding and decoding. Both eventually pass everything down the pipeline to ALSA.

aRts has been officially deprecated by the KDE team for KDE4, and will be replaced by Phonon. Phonon promises a simpler API (application programming interface) by functioning more as a universal interface between existing audio engines such as ALSA, Xine, MPLayer, and VLC. The Phonon developers also have the worthy goal of designing a friendlier mixer interface that doesn't require knowledge of sound engineering terminology, but uses sensible labels like Notifications, Music, and Communications.

But that's not all. Some applications, for example MPlayer and Xine, do everything themselves and do not rely on a sound server. While this might not bother end users, it is a nightmare for developers who have to write support for all these different beasts into their applications. In fact, the fractured nature of audio systems and their many diverse APIs in Linux is a chronic problem for developers.

While describing the current state of Linux audio would require a book, this should give you an idea of its complexity, pitfalls, and boobytraps. The good news is we have a lot of great audio applications. The bad news is it's all rather a messy jumble. But that, perhaps, is changing. If your Linux audio needs are simple, stick with ALSA. It works on all Linuxes and it works just fine. If your needs are more complex, then you want to look at more complex sound servers.

PulseAudio is intended to be a drop-in replacement for ESD on Gnome. It is designed to be cross-platform, running on POSIX-compliant operating systems (like Linux), and on Win32. Before I discuss PulseAudio further, I must share an amusing true anecdote, which I promise is relevant. A good friend of mine has a number of health problems, so he spends a lot of time seeing doctors and taking a lot of medications. His favorite doctor is a Vietnamese woman with a bent sense of humor. He told her he didn't like how a certain drug was making him feel. She prescribed an additional medication. He asked why didn't she give him something to replace the nasty one, and she said "We never replace, we only add." She wasn't serious, but there was a grain of truth in it. And so it is with Linux applications and subsystems--it seems we never replace, only add.

However, PulseAudio has the potential to become the common Linux audio server, and actually replace some legacy servers like ESD and aRts. Why would we even want this? For one thing, it has a great advanced feature set:

• Individual volume controls for each playback stream
• Modular, extensible architecture
• Multiple backends for compatibility with other audio servers
• A consistent and common API
• Low-latency
• Auto-discovery of other Pulse-enabled computers on a network
• Network sound server
• Mix-and-match multiple sound devices and playback streams
• USB hotplug support
• Both GUI and command-line controls

Next week we'll install PulseAudio on some random Linux and learn some useful and cool things to do with it, and some tips and tricks for getting past some of the bumpy parts.

Resources

• PulseAudio
• Interviews/LennartPoettering

This article was first published on LinuxPlanet.com.

PulseAudio Tames the Linux Audio Zoo, Part 2
By Carla Schroder
June 30, 2008

Last week we learned a bit about the chaotic jumble that is audio on Linux, and about the new PulseAudio sound server that just may create bit of order, and perhaps some more user-friendliness. Several Linux distributions default to using PulseAudio, such as Fedora, Ubuntu Hardy Heron, and Mandriva. Many others now include it in their software repositories, or you can follow this guide for installing the latest version from source code.

Application support for PulseAudio is not quite complete. Notable problem applications are Skype, Flash Player, and Real Player. I shall refrain from my usual sarcastic commentary on the inability of the vendors of closed, proprietary applications to keep pace with FOSS development, because a person should exhibit a bit of class now and then, however insincere. Visit The Perfect Setup for instructions on getting these to work.

I had originally intended to make this as general a guide as possible, but I ran into a number of problems on both Kubuntu Gutsy and Hardy and got all wrapped up in debugging them, so today is going to be Fix *buntu Day. This may be useful to users on other other distributions as well because it covers permission problems, ALSA problems, and init problems, so everyone is welcome to tag along.

PulseAudio has a collection of good user-space utilities:

• Device Chooser
• Volume Control
• Volume Meter
• Manager
• Preferences

After installation, run a simple command-line test:

$  pulseaudio --version

W: main.c: WARNING: called SUID root, but not in group 'pulse-rt'.
pulseaudio 0.9.6

pulse-rt stands for "pulse real-time", and you need to be a member of the pulse-rt group to get rid of this warning. The easy and safe way is to edit the /etc/group file directly:

pulse-rt:x:125:carla

Anytime you change your group memberships you have to log out and then log back in to activate the changes, so do that next. After logging back in, check your group membership:

$ groups
carla adm dialout floppy audio dip video plugdev fuse lpadmin admin pulse-rt

It isn't strictly necessary to do this, but enabling realtime priority means better audio quality.

We still need ALSA compatibility, so add these lines to /etc/asound.conf:

pcm.pulse {type pulse}
ctl.pulse {type pulse}

Now find yourself a nice WAV file to play and give it a whirl:

$  aplay -D pulse music/1st-set.wav
*** PULSEAUDIO: Unable to connect: Connection refused
aplay: main:545: audio open error: Connection refused

Oops. A quick ps ax|grep pulse reveals that the PulseAudio daemon isn't even running. Another symptom of this is when you open the graphical Pulse Audio Manager, you see something like Figure 1 with a "connection refused" message. So what to do?

PulseAudio can run as an ordinary system-wide daemon if you wish. To enable this, edit /etc/default/pulseaudio like this:

PULSEAUDIO_SYSTEM_START=1
DISALLOW_MODULE_LOADING=0

That should be the opposite of the default. Then any user that needs access to the Pulse server needs to be added to the pulse-access group, including root. Then start it in the usual way:

$ sudo /etc/init.d/pulseaudio start

 * Starting PulseAudio Daemon      [ OK ]

Now when you open the PulseAudio Manager it looks like Figure 2, and aplay will play your file.

But on a multi-user system this is not the best way to run PulseAudio, according to the developers. It is better to run it per-user for these reasons: it creates a potential security hazard because it runs SUID, users can mess with other users' sound, and settings are system-wide instead of individualized. If you're on a single-user system then it doesn't matter.

If you want it to run per-user, then each user needs individual configuration and startup files. PulseAudio is already well-integrated into Gnome, and Gnome supports per-session startup, so the hard work is already done. If you're running a distribution that does not default to PulseAudio, create a symlink from Pulse's compatibility script to the ESD binary to load PulseAudio instead:

# ln -sf /usr/local/bin/esdcompat /usr/bin/esd

Verify your filepaths first, of course.

What do users of other desktop environments do? We'll get into detail on that next week. Meanwhile, KDE users can do this: stop it by running sudo /etc/init.d/pulseaudio stop, then reverse the changes to /etc/default/pulseaudio so that it does not start at boot. Then start it manually like this:

$ pulseaudio --high-priority --log-target=syslog

Check out the various userland tools, which you should find in your multimedia menu, and next week we'll learn how to configure per-user startup, learn about sinks and sources, and play networked sounds.

Resources

• SUID programs, getting to the root of the problem
• PulseAudio
• Interviews/LennartPoettering

Carla Schroder is the author of the Linux Cookbook and the newly-released Linux Networking Cookbook, and is a regular contributor to LinuxPlanet.