This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


Sound in GNU/Linux

By Jem Matzan on October 29, 2004 (8:00:00 AM)

Share    Print    Comments   

Getting sound to work properly in GNU/Linux can be a real pain (not 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.


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 | more in GNU/Linux to see what's loaded. If you 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.


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 settings
alsactl 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.

Share    Print    Comments   


on Sound in GNU/Linux

Note: Comments are owned by the poster. We are not responsible for their content.

sp/dif digital out

Posted by: Anonymous Coward on November 09, 2004 11:26 AM
Would liked to have seen a section on this as well, a lot of todays addon boards have digital in and outs of one kind or another. I haven't really looked too hard yet but I can't get my Live! 5.1 to output via spdif to my amp.


how-to : software mixing with ALSA

Posted by: Anonymous Coward on November 15, 2004 02:33 PM
<A HREF="" title=""></a>


Re:pops and clicks

Posted by: Anonymous Coward on December 30, 2004 06:42 AM
I get the same pops and clicks on my Shuttle with FC 3 - x86_64.



Re:pops and clicks

Posted by: Anonymous Coward on December 30, 2004 06:52 AM
well.. i don't know what the root cause was, but i have eliminated the noise in my system by muting the "IEC958 input monitor" in the switches panel of kmix.

i have nfi what this actually controls, but that definitely was the source of the pops and clicks.


Re:pops and clicks

Posted by: Jem Matzan on November 02, 2004 04:59 AM
I've never seen software cause that, unless it's rythmic, in which case it could be a buffering or sound quality/compression problem.

I'd say it's more likely that the problem is in the hardware somewhere. Try moving the speaker cord around and see if it gets any worse. Also try turning the volume on the speakers up and down to see if it gets better or worse. You can also try different speakers (headphones are good for testing) and also try different output jacks if your XPC has more than one.



pops and clicks

Posted by: Administrator on November 02, 2004 12:13 AM
I was hoping to see pops and clicks among your typical sound issues. I get this on a Shuttle XPC running Fedora, and none of the control panel settings available from KDE seem to fix it.

ARTS, OSS<nobr> <wbr></nobr>.. changing those don't help either.

It sort of sounds like a buffer thing - like there isn't one.

Any ideas?


good starting point ...

Posted by: Administrator on November 10, 2004 02:54 AM
i've recently had a lot of problems with sound on fedora core 2 (x86_64) and suse 9.1 pro (x86_64). i was especially disappointed in suse since i payed for it expecting 3 months support - WHICH DOESN'T INCLUDE SOUND (read the fine print before you buy!). posting to alsa didn't get a response either since, i imagine, my problems weren't advanced enough or the answer was somewhere in the archives of the last year.

all i wanted to do was a simple line-in recording from vinyl on an audigy soundcard. i first wanted to make sure all the basics were in order and i had a hard time piecing together that information. a good basic explanation on sound in linux was sadly lacking and that's where an article like this would have come in handy. i finally dug up an old linux format which had a pretty extensive treatment of alsa. ultimately, i went back to the distro i know best, slackware (10.0), and worked uniquely with command line apps (alsa-utils). all the basics were set up correctly and through a process of trial and error discovered which of 37 mixer settings i had to turn up. success, but i'm still working on the finer points of determining the right levels to get undistorted sound, using normalize, etc.

does it or should it take a week to get all this sorted out? ( to rtfm i respond w(which)fm?). i had to deal with a number of broken gui apps and sift through months of alsa archives. the alsa wiki pages seem to be a good start for finding simple how-tos but i think a lot more has to be done. their adage appears to be, "why make it complicated when we can make it VERY complicated".
there needs to be a simplification or division of those mixer settings into 'advanced' or a la windows, 'playback/record'. i appreciate that alsa does important work and caters to people with much more involved issues than mine, but somewhere there's got o be a venue for the run-of-the-mill desktop sod!?, who just wants to listen to some bob marley and have the bass and treble mixers actually do something!

desktop sod


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya