Author: Preston St. Pierre
that it can’t be in Windows, too), and even if it works perfectly from
the start, the technologies that live between you and the hardware are
often confusing and mysterious. This article outlines ALSA, OSS,
Esound, and aRts and what they do; we’ll also list some tips for identifying your sound card or onboard sound chip and for getting sound to work in GNU/Linux.
There are two distinct layers to the sound system in GNU/Linux: the kernel driver and the sound server. You need the driver for the sound card to work with the operating system, but the sound server is optional. While you don’t need it to play sound, you do need it to play more than one sound at once, and some servers have more features than just managing sound requests.
First, you’re far better off with the 2.6 Linux kernel than the 2.4,
as all versions of 2.6 have ALSA included and most versions of 2.4 do not. Downloading and installing
the ALSA drivers for 2.4 is possible, but it’s a far messier
solution than relying on the kernel and base system to provide hardware functionality.
The rest of this article assumes you’re using some variation of the
2.6 kernel, although most of this material applies to GNU/Linux in general and is not kernel-specific.
Kernel drivers: OSS and ALSA
The Open Sound System (OSS) and the Advanced Linux Sound
Architecture (ALSA) are two sets of kernel-level drivers for
sound cards. The proper kernel driver must be either
compiled into the kernel or loaded as a module; there does not appear
to be any difference in performance or compatibility between the two
methods, so the choice is left to personal preference, assuming you are compiling the kernel yourself. If you’re using a binary or commercial distribution, chances are good that all of the modules you might need are already compiled, and the system should load the proper sound driver at boot time.
The OSS drivers are produced by 4Front Technologies, which also maintains the XMMS media player. The OSS code in the Linux kernel is BSD licensed, and as a result they are allowed commercial counterparts, which are available for purchase through the OpenSound Web site.
The commercial drivers of course come with commercial support. All of the OSS
drivers in the Linux kernel are free to use, but the ones you download from the OpenSound site are proprietary. OSS makes drivers for a wide variety of sound cards and operating systems; if you’re using a proprietary Unix or some form of BSD Unix, OSS is probably the only way to hear sound from your sound card.
OSS is merely an interface between software applications and the hardware, so it’s a “bare” driver, although you can also get an OSS mixer application as well. It’s basic, but fast and efficient.
GNU/Linux users have OSS drivers available in the kernel, but they also have ALSA, which was originally based on OSS and is backwards compatible with it. ALSA is more than just a driver — it’s a tool set, utility package, and an architecture for creating music. It interacts with
cheap consumer-grade sound chips and commercial sound boards alike; in
other words it’s more versatile and supports a more diverse range of devices than the free OSS drivers.
People inevitably ask which is “better.” The answer is contingent on the brand and model of sound card you have, what distribution you’re using, and what you need to do with your sound device. OSS drivers are available for nearly every current Unix and Unix-like platform, from AIX to UnixWare. ALSA drivers are specific to the Linux kernel and don’t support as wide a range of devices as the commercial OSS drivers (for a complete list of ALSA-compatible sound cards, click here; OpenSound’s compatibility list is here).
Both ALSA and OSS (the noncommercial edition, of course) are built into the Linux kernel, but OSS has been deprecated in favor of ALSA in the 2.6 kernel. That doesn’t mean you can’t use it, but it
does mean that the powers that be have decided that ALSA is the way the
kernel should be headed. In terms of performance, ALSA processes run in
user space, and ALSA accomplishes most of its functionality through
libraries. OSS goes directly to the kernel, and as a result it should be quicker and more efficient on most
systems, although I doubt most people would notice any difference in performance.
If you have a choice, I recommend going with ALSA if you’re on GNU/Linux, if for no
other reason than GNU/Linux is better equipped to work with it. Mixer
software and other userland ancillary programs are usually geared for ALSA instead
of OSS. But for those programs that demand OSS, ALSA is fully binary
compatible with it. There is no harm in compiling both the OSS and the ALSA drivers, if you really want to have both on your system.
Sound daemons: aRts, EsounD and others
On top of the bottom software layer you have whatever is running in
user space. If that’s just one program producing one sound at a time,
you’ll never have any trouble. But if you have several programs
fighting with each other over the one sound device, that presents a
problem. Enter the sound server (or daemon). This piece of software acts as a
multitasking traffic cop, allowing all sounds to reach the sound device
at the requested time without conflict. The Enlightened Sound Daemon (EsounD or ESD for short) and the Analog Realtime Synthesizer (aRts) are the two most common sound servers in
the Linux universe.
EsounD is old, barely developed anymore, and can only manage and
route sound traffic. aRts, on the other hand, does more than just allow
multiple sounds to play concurrently; it is also a modular framework
that combines several software components to create music and sounds. aRts is an
integral part of the K Desktop
Environment, but it does not require the usual KDE
tagalongs (Qt, KDE-libs, KDE-multimedia, etc.), so you can easily install
it separately if you’d like.
Both sound daemons are network-transparent and can control sound from a remote server.
ESD and aRts are the two most often used sound servers, but there
are a few more out there, such as BEAST/BSE, MAS, and CSL. I’m not aware of any major distributions that use these servers by default, but that doesn’t mean they aren’t worth investigating if you’re serious about sound.
Installation
How do you install a sound package? Please note that these instructions are basic; in many instances you will need to do one or two things extra (or just a little differently) for specific sound cards and distributions. Debian, for instance, often requires extra steps to install sound drivers properly. If you’re using ALSA, its driver and sound card reference page provides card- and distro-specific instructions.
So you want to get your sound card working — no problem. First you
need to make sure that you have a driver loaded for it. If you’re using
a commercial distribution like SUSE or Xandros, chances are the driver
will be loaded if it is available. Commercial distros usually load
all peripheral drivers as modules, so simply run lsmod in GNU/Linux to see what’s loaded. If you
| more
recognize the module for your sound card or sound chip in that list, you’re
ready for the next step.
If you do not see your card in that list, or if you’re using a
community distribution like Gentoo or Debian, you’ll probably have to compile the driver. To do that, you first need the source code for your running kernel. Once the source is installed, go into your kernel config file and find the entry for your sound card. It’ll be listed in Device Drivers -> Sound -> Advanced Linux Sound Architecture -> PCI Devices. If you’re compiling the OSS driver, choose Open Sound System instead of Advanced Linux Sound Architecture. It’s much faster and easier to compile the driver as a module, but it’s easier in the long run to build the sound driver into the kernel and rebuild everything. The choice is yours, but we’re only going to cover the module method, as it is the more complex procedure.
Choose the option to compile as a module. Write down the name of your sound card’s module — sometimes it isn’t obvious, and you’ll need to know the module name later on. If it isn’t displayed in the config menu, press the ? key to see the module name and a short description of it. When you’re done, exit the config utility and save the configuration. Then enter this command:
make modules && make modules_install
Some distributions can load modules on startup without you telling them to; others, especially community distributions, require you to either load the module by hand using modprobe, or at startup automatically by adding the module name to your /etc/modules.autoload file (the name of this file can vary somewhat between distros, but it should be recognizable).
Once the module is loaded, you have sound capabilities. The next step is to make sure your mixer is configured properly — the default settings in most instances will be to mute the speakers and microphone. First check to see if you have a program called alsamixer, which is part of the alsa-utils package. If you have it, run alsamixer from the command line and set your levels. If you don’t have it, you can install alsa-utils or alsamixer through your distribution’s package management system (APT, Portage, Yum), or you can download it here from the ALSA project Web site.
If you compiled OSS drivers only, you obviously don’t need the ALSA mixer. OpenSound offers its own mixer applet, which you can download for free, but it requires the Qt toolkit and runs only from X11.
Lastly, add the alsasound rc script to your default runlevel. If you’re using a mixer application with an init script, add that as well — otherwise you’ll have to set your levels every time you restart the computer.
Installing sound daemons is fairly straightforward. If you have KDE installed on your system, you already have aRts. If for some reason you really want to use EsounD, you can download it here or install it through your distribution’s package management system. You may already have EsounD installed if you’re using the Enlightenment or Window Maker window managers. If you want these sound servers to start by default at boot time, you’ll probably have to add their rc scripts to your default runlevel.
Troubleshooting
These are the most common issues I’ve seen with sound in GNU/Linux. Certainly there are more, and some that will be specific to certain models of sound cards and sound chips. This, like everything else, is not intended to be a comprehensive listing.
If you don’t know what sound card or sound chip you have in your system, the best way to find out is to check the computer or motherboard manufacturer’s Web site. If there is no listing of what was originally installed in your system and what sound chip it uses, call your manufacturer’s tech support line and ask. If you’re feeling particularly adventurous, you can open up your chassis and try to find the sound chip on your motherboard (or the sound card, if you’re using a PCI sound solution). Usually it’s located under the I/O backplane near the PCI slots. Most sound chips have the manufacturer’s name printed clearly on them, but Analog Devices usually just lists a model number starting with AD, as in AD1980.
Sound chips are made by only a handful of companies, and above all there are two that are particularly common: Analog Devices (AD) and Realtek. The others are Nvidia (nForce SoundStorm), SiS, ESS, and Yamaha. Most brands and models are supported by ALSA; it’s only a matter of figuring out which module needs to be loaded. We’re not going to list every module and what cards they control; ALSA has a page for that.
If the correct module is already loaded but there is still no sound, make sure that the volume is turned up in the mixer. By default, the volume is muted in most implementations of ALSA. You can change the volume from KMix in KDE, Volume Control in GNOME, or various command line mixers. I’ve found the best one to be aumix, as it usually has a lot of control over more complex sound cards.
If you find that your sound is muting itself every time you restart your computer despite changing it afterward, the problem is that the settings are not being saved and then reloaded at startup. If you’re using aumix, the solution is easy: first, set your levels with aumix, then add both the alsasound and aumix rc scripts (usually found in /etc/init.d/) to your default runlevel. From then on, your system will start with the last levels you saved. If you do not have aumix or don’t want to use it, then you can use alsactl to solve the problem. First, set your levels with alsamixer then as root, type:
alsactl store
Next, edit your /etc/rc.d/rc.local file and add these lines at the end:
# The following restores ALSA mixer settingsalsactl restore 0
If you’re not hearing sound from a music CD playing in your optical drive, the most common cause is a lack of an internal analog audio cable going from the drive to the sound card or motherboard. Windows uses digital audio extraction (DAE) to play CDs, so the analog cable is not necessary and often not included with newer computers. You can find one at your local computer store for less than $5, or you can get one online rather easily. Modern IDE optical drives and sound cards use only the larger black connectors, not the smaller white ones that older drives used. Plug your analog cable into the back of the optical drive (there’s only one place and one way that it will fit) and into the matching “CDROM” connector on your sound card or motherboard. If you have two optical drives, use the “AUX” connector, but never use the one marked “MODEM” or “PHONO” — that is reserved for internal modems and is a very low-quality sound connection. It’s somewhat rare to see that latter type of connector on today’s sound peripherals, probably to save manufacturing costs and space, and because fewer people are using internal modems these days.
Additionally you’ll want to make sure that the volume is turned up and unmuted for the CD and AUX devices in your mixer.
Sound in Linux
Setting up sound in GNU/Linux is not difficult if you know what to check and what to install. Usually most of these things are done for you automatically in today’s distributions, so chances are, if sound is not working for you by default, there are just one or two of the above-listed items that need adjustment.
If you’d like to add your own tips and recommendations, or if you have a question that isn’t covered in this article, feel free to write it in the comment section below.
Jem Matzan is the author of three books, a freelance journalist and the editor-in-chief of The Jem Report.
