Configuring Linux to support sound involves the following steps:
The next sections will cover each of these steps in detail.
Follow the manufacturer's instructions for installing the hardware or have your dealer perform the installation.
Older sound cards usually have switch or jumper settings for IRQ, DMA channel, etc; note down the values used. If you are unsure, use the factory defaults. Try to avoid conflicts with other devices (e.g. ethernet cards, SCSI host adaptors, serial and parallel ports) if possible.
Usually you should use the same I/O port, IRQ, and DMA settings that work under DOS. In some cases though (particularly with PnP cards) you may need to use different settings to get things to work under Linux. Some experimentation may be needed.
When initially installing Linux you likely used a precompiled kernel. These kernels usually do not provide sound support. It is best to recompile the kernel yourself with the drivers you need. You may also want to recompile the kernel in order to upgrade to a newer version or to free up memory resources by minimizing the size of the kernel.
The Linux Kernel HOWTO should be consulted for the details of building a kernel. I will just mention here some issues that are specific to sound cards.
If you have never configured the kernel for sound support before it is a good idea to read all of the Readme files included with the kernel sound drivers, particularly information specific to your card type. The following documentation files can be found in the kernel sound driver directory, usually installed in /usr/src/linux/drivers/sound:
CHANGELOG - description of changes in each release COPYING - copying and copyright restrictions Readme - latest and most important news Readme.aedsp16 - information about Audio Excel DSP 16 sound card Readme.cards - notes on configuring specific cards Readme.linux - notes on installing separately release sound drivers Readme.modules - how to build driver as a loadable kernel module Readme.v30 - new features in version 3.0 sound driver experimental.txt - notes on experimental features
Follow the usual procedure for building the kernel. There are currently three interfaces to the configuration process. A graphical user interface that runs under X11 can be invoked using "make xconfig". A menu-based system that only requires text displays is available as "make menuconfig". The original method, using "make config", offers a simple text-based interface.
Special care must be taken when using "make xconfig" or "make menuconfig". All Yes/No questions must be examined carefully. The default answer provided by these commands is always No which is not the proper one in all cases. In particular the "/dev/dsp and /dev/audio support" (CONFIG_AUDIO) option should usually be enabled.
In this document I will assume that you use the traditional command line configuration process invoked using "make config", although the process is similar in each case.
There are also two different ways to configure sound. The first is the "old" way (the only one offered prior to the 2.0.0 kernels). It uses a standalone configuration program that is part of the sound driver. This method works with most sound cards except the rare few that require additional "low level" drivers (miroSOUND, AWE32, and AEDSP16 cards).
The second is the "new" method which is better integrated with the menu-based configuration used for the rest of the kernel. This one doesn't work with sound cards that require a firmware download file. This includes the PSS, SM Wave, AudioTrix Pro and TurtleBeach Tropez/Maui cards. With these cards the old method has to be used.
The "new" method is always used by "make xconfig". When using "make menuconfig" you can select between the "old" and "new" methods in the sound subscreen. When using "make config" you get the "old" method by default. However if you have used the "new" method once, it will be used by "make config" too. You can switch back to the "old" method by running "make menuconfig" and by selecting the "old" one.
The recommended method is to use "make menuconfig" together with the "old" sound config method. Many sound configuration problems are caused (at least partly) by incorrect use of the "new" method.
It is also possible to build the sound driver as a kernel loadable module. I recommend initially building the driver into the kernel. Once it is tested and working you can explore using the kernel module option.
When you run make config, enable sound support by answering
"y" to the question
Sound card support (CONFIG_SOUND) [M/n/y/?]
At the end of the configuration questions a sound configuration program will be compiled, run, and will then ask you what sound card options you want. Be careful when answering these questions since answering a question incorrectly may prevent some later ones from being asked. For example, don't answer "yes" to the first question (PAS16) if you don't really have a PAS16. Don't enable more cards than you really need, since they just consume memory. Also some drivers (like MPU-401) may conflict with your SCSI controller and prevent the kernel from booting.
I list here a brief description of each of the configuration dialog options. Answer "y" (yes) or "n" (no) to each question. The default answer is shown so that "[Y/n/?]" means "y" by default and "[N/y/?]" means the default is "n". To use the default value, just hit Enter, but remember that the default value isn't necessarily correct.
Entering a question mark ("?") will produce a short descriptive message describing that configuration option.
Note also that all questions may not be asked. The configuration program may disable some questions depending on the earlier choices. It may also select some options automatically as well.
If you have previously compiled the kernel for sound support, then the previous configuration can be saved. If you want to use the previous setup, answer "y". If you are trying a different configuration or have upgraded to a newer kernel, you should answer "n" and go through the configuration process.
Answer "y" only if you have a Pro Audio Spectrum 16, ProAudio Studio 16 or Logitech SoundMan 16. Don't answer 'y' if you have some other card made by Media Vision or Logitech since they are not PAS16 compatible.
Answer "y" if you have an original SoundBlaster card made by Creative Labs or a 100% hardware compatible clone (like the Thunderboard or SM Games). If your card was in the list of supported cards look at the card specific instructions in the Readme.cards file before answering this question. For an unknown card you may answer "y'"if the card claims to be SoundBlaster compatible.
Answer "y" if you have a GUS or GUS MAX. Answer "n" if you don't have a GUS since the driver consumes a lot of memory.
Be careful with this question. The MPU-401 interface is supported by almost all sound cards. However, some natively supported cards have their own driver for MPU-401. Enabling the MPU-401 option with these cards will cause a conflict. Also enabling MPU-401 on a system that doesn't really have a MPU-401 could cause some trouble. If your card was in the list of supported cards, look at the card specific instructions in the Readme.cards file. It's safe to answer "y" if you have a true MPU-401 MIDI interface card.
It's safe to answer "n" to this question in all cases. The 6850 UART interface is very rarely used.
Answer "y" only if you have Orchid SW32, Cardinal DSP16 or some other card based on the PSS chipset (AD1848 codec + ADSP-2115 DSP chip + Echo ESC614 ASIC CHIP).
Answer "y" if you have installed the 16 bit sampling daughtercard on your GUS. Answer "n" if you have a GUS MAX. Enabling this option disables GUS MAX support.
Answer "y" only if you have a GUS MAX.
Again think carefully before answering "y" to this question. It's safe to answer "y" if you have the original Windows Sound System card made by Microsoft or Aztech SG 16 Pro (or NX16 Pro). Also you may answer "y" in case your card was not listed earlier in this file. For cards having native support in VoxWare, consult the card specific instructions in Readme.cards. Some drivers have their own MSS support and enabling this option will cause a conflict.
Answer "y" if you have a sound card based on the Ensoniq SoundScape chipset. Such cards are being manufactured at least by Ensoniq, Spea and Reveal (Reveal makes other cards also).
Answer "y" if you have the AudioTriX Pro.
Answer "y" if your card has a Mozart (OAK OTI-601) or MAD16 (OPTi 82C928 or 82C929) audio interface chip. These chips are currently quite common so it's possible that many no-name cards have one of them. In addition the MAD16 chip is used in some cards made by known manufacturers such as Turtle Beach (Tropez), Reveal (some models) and Diamond (latest ones).
Answer "y" if you have a card based on the Crystal CS4232 chip set.
Answer "y" if you have any of these cards.
Enable this option if your card is a SoundBlaster Pro or SoundBlaster 16. Enable it also with any SoundBlaster Pro clones. Answering "n" saves some memory but "y" is the safe alternative.
Enable if you have a SoundBlaster 16 (including the AWE32).
Enable this if you have an Audio Excel DSP16 card. See the file Readme.aedsp16 for more information.
The configuration program then asks some questions about the higher level services. It's recommended to answer "y" to each of these questions. Answer "n" only if you know you will not need the option.
Answering "n" disables /dev/dsp and /dev/audio, the A/D and D/A converter devices. Answer "y".
Answering "n" disables /dev/midixx devices and access to any MIDI ports using /dev/sequencer and /dev/music. This option also affects any MPU-401 and/or General MIDI compatible devices.
Answer "y" here.
Answering "n" disables /dev/sequencer and /dev/music
Answer "y" if you have a Sound Galaxy NX Pro sound card and want support for its extended mixer functions.
Answer "y" if you have an MV Jazz16 sound card.
Answer "y" if you have a Logitech SoundMan Games sound card.
After the above questions the configuration program prompts for the card specific configuration information. Usually just a set of I/O address, IRQ and DMA numbers are asked. With some cards the program asks for some files to be used during initialization of the card. These are used by cards which have a DSP chip or microprocessor which must be initialized by downloading a program (microcode) file to the card. In some cases this file is written to a .h file by the config program and then included to the driver during compile. Again, read the information in the file Readme.cards pertaining to your card type.
At the end you will be prompted:
The sound driver is now configured.
Save copy of this configuration to /etc/soundconf [Y/n/?]
Normally you would enter "y" so that if you later need to recompile the kernel you have the option of using the same sound driver configuration.
If you are upgrading from an older sound driver, make sure that the
files /usr/include/sys/soundcard.h and
/usr/include/sys/ultrasound.h are symbolic links to the
corresponding files in /usr/include/linux, or that they
simply contain the lines #include <linux/soundcard.h>
and #include <linux/ultrasound.h>, respectively.
You are now ready to compile and install the new kernel.
For proper operation, device file entries must be created for the sound devices. These are normally created for you during installation of your Linux system. A quick check can be made using the command listed below. If the output is as shown (the date stamp will vary) then the device files are almost certainly okay.
% ls -l /dev/sndstat
crw-rw-rw- 1 root root 14, 6 Apr 25 1995 /dev/sndstat
Note that having the right device files there doesn't guarantee anything on its own. The kernel driver must also be loaded or compiled in before the devices will work (more on that later).
In rare cases, if you believe the device files are wrong, you can
recreate them using the short shell script from the end of the file
Readme.linux in the directory
/usr/src/linux/drivers/sound, running it as user
root. Alternatively, most Linux distributions have a
/dev/MAKEDEV script which can be used for this purpose.
If you are using the PC speaker sound driver, read the documentation that came with the package to determine if any device files need to be created.
You should now be ready to boot the new kernel and test the sound drivers. Follow your usual procedure for installing and rebooting the new kernel (keep the old kernel around in case of problems, of course).
During booting, check for a message such as the following on powerup
(if they scroll by too quickly to read, you may be able to retrieve
them with the dmesg command):
Sound initialization started
<Sound Blaster 16 (4.13)> at 0x220 irq 5 dma 1,5
<Sound Blaster 16> at 0x330 irq 5 dma 0
<Yamaha OPL3 FM> at 0x388
Sound initialization complete
This should match your sound card type and jumper settings (if any).
Note that the above messages are not displayed when using loadable sound driver module (unless you enable it, e.g. using "insmod sound trace_init=1).
When the sound driver is linked into the kernel, the "Sound initialization started" and "Sound initialization complete" messages should be displayed. If they are not printed, it means that there is no sound driver present in the kernel. In this case you should check that you actually installed the kernel you compiled when enabling the sound driver.
If nothing is printed between the "Sound initialization started" and the "Sound initialization complete" lines, it means that no sound devices were detected. Most probably it means that you don't have the correct driver enabled, the card is not supported, the I/O port is bad or that you have a PnP card that has not been configured.
The driver may also display some error messages and warnings during boot. Watch for these when booting the first time after configuring the sound driver.
Next you should check the device file /dev/sndstat. Reading the sound driver status device file should provide additional information on whether the sound card driver initialized properly. Sample output should look something like this:
% cat /dev/sndstat
Sound Driver:3.5.4-960630 (Sat Jan 4 23:56:57 EST 1997 root,
Linux fizzbin 2.0.27 #48 Thu Dec 5 18:24:45 EST 1996 i586)
Kernel: Linux fizzbin 2.0.27 #48 Thu Dec 5 18:24:45 EST 1996 i586
Config options: 0
Installed drivers:
Type 1: OPL-2/OPL-3 FM
Type 2: Sound Blaster
Type 7: SB MPU-401
Card config:
Sound Blaster at 0x220 irq 5 drq 1,5
SB MPU-401 at 0x330 irq 5 drq 0
OPL-2/OPL-3 FM at 0x388 drq 0
Audio devices:
0: Sound Blaster 16 (4.13)
Synth devices:
0: Yamaha OPL-3
Midi devices:
0: Sound Blaster 16
Timers:
0: System clock
Mixers:
0: Sound Blaster
The command above can report some error messages. "No such file or directory" indicates that you need to create the device files (see section 4.3). "No such device" means that sound driver is not loaded or linked into kernel. Go back to section 4.2 to correct this.
If lines in the "Card config:" section of /dev/sndstat are listed inside parentheses (such as "(SoundBlaster at 0x220 irq 5 drq 1,5)"), it means that this device was configured but not detected.
Now you should be ready to play a simple sound file. Get hold of a sound sample file, and send it to the sound device as a basic check of sound output, e.g.
% cat endoftheworld >/dev/dsp
% cat crash.au >/dev/audio
(Make sure you don't omit the ">" in the commands above).
Note that, in general, using cat is not the proper way to
play audio files, it's just a quick check. You'll want to get a proper
sound player program (described later) that will do a better job.
This command will work only if there is at least one device listed in the audio devices section of /dev/sndstat. If the audio devices section is empty you should check why the device was not detected.
If the above commands return "I/O error", you should look at the end of the kernel messages listed using the "dmesg" command. It's likely that an error message is printed there. Very often the message is "Sound: DMA (output) timed out - IRQ/DRQ config error?". The above message means that the driver didn't get the expected interrupt from the sound card. In most cases it means that the IRQ or the DMA channel configured to the driver doesn't work. The best way to get it working is to try with all possible DMAs and IRQs supported by the device.
Another possible reason is that the device is not compatible with the device the driver is configured for. This is almost certainly the case when a supposedly "SoundBlaster (Pro/16) compatible" sound card doesn't work with the SoundBlaster driver. In this case you should try to find out the device your sound card is compatible with (by posting to the comp.os.linux.hardware newsgroup, for example).
Some sample sound files can be obtained from ftp://tsx-11.mit.edu/pub/linux/packages/sound/snd-data-0.1.tar.Z
Now you can verify sound recording. If you have sound input capability, you can do a quick test of this using commands such as the following:
# record 4 seconds of audio from microphone
EDT% dd bs=8k count=4 </dev/audio >sample.au
4+0 records in
4+0 records out
# play back sound
% cat sample.au >/dev/audio
Obviously for this to work you need a microphone connected to the sound card and you should speak into it. You may also need to obtain a mixer program to set the microphone as the input device and adjust the recording gain level.
If these tests pass, you can be reasonably confident that the sound D/A and A/D hardware and software are working. If you experience problems, refer to the next section of this document.
If you still encounter problems after following the instructions in the HOWTO, here are some things to check. The checks are listed in increasing order of complexity. If a check fails, solve the problem before moving to the next stage.
You can check the date stamp on the kernel to see if you are running
the one that you compiled with sound support. You can do this with the
uname command:
% uname -a
Linux fizzbin 2.0.0 #1 Tue Jun 4 16:57:55 EDT 1996 i386
or by displaying the file /proc/version:
% cat /proc/version
Linux version 2.0.0 (root@fizzbin) (gcc version 2.7.0) #1 Tue Jun 4 16:57:55 EDT 1996
If the date stamp doesn't seem to match when you compiled the kernel, then you are running an old kernel. Did you really reboot? If you use LILO, did you re-install it (typically by running /etc/lilo/install)? If booting from floppy, did you create a new boot floppy and use it when booting?
The easiest way to do this is to check the output of "dev/sndstat" as described earlier. If the output is not as expected then something went wrong with the kernel configuration or build. Start the installation process again, beginning with configuration and building of the kernel.
Make sure that the sound card was detected when the kernel booted. You
should have seen a message on bootup. If the messages scrolled off the
screen, you can usually recall them using the dmesg command:
% dmesg
or
% tail /var/adm/messages
If your sound card was not found then something is wrong. Make sure it really is installed. If the sound card works under DOS then you can be reasonably confident that the hardware is working, so it is likely a problem with the kernel configuration. Either you configured your sound card as the wrong type or wrong parameters, or your sound card is not compatible with any of the Linux kernel sound card drivers.
One possibility is that your sound card is one of the "compatible"
type that requires initialization by the DOS driver. Try booting DOS
and loading the vendor supplied sound card driver. Then soft boot
Linux using Control-Alt-Delete. Make sure that card I/O
address, DMA, and IRQ settings for Linux are the same as used under
DOS. Read the Readme.cards file from the sound driver
source distribution for hints on configuring your card type.
If your sound card is not listed in this document, it is possible that the Linux drivers do not support it. You can check with some of the references listed at the end of this document for assistance.
Try reading from the /dev/audio device using the dd
command listed earlier in this document. The command should run
without errors.
If it doesn't work, then chances are that the problem is an IRQ or DMA conflict or some kind of hardware incompatibility (the device is not supported by Linux or the driver is configured for a wrong device).
A remote possibility is broken hardware. Try testing the sound card under DOS, if possible, to eliminate that as a possibility.
If you still have problems, here are some final suggestions for things to try:
comp.os.linux or other
Usenet newsgroups (comp.os.linux.hardware is a good choice; because of
the high level of traffic in these groups it helps to put the string
"sound" in the subject header for the article so the right experts
will see it)Esc-x doctor :-)