Previous Next Contents

4. Installation

Configuring Linux to support sound involves the following steps:

  1. Installing the sound card.
  2. Configuring and building the kernel for sound support.
  3. Creating the device files.
  4. Booting the Linux kernel and testing the installation.

The next sections will cover each of these steps in detail.

4.1 Installing the Sound Card

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.

4.2 Configuring the Kernel

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. When you run make config, enable sound support by answering "yes" to the question

Sound card support?

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 MPU401) 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.

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.

ProAudioSpectrum 16 support?

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.

SoundBlaster support?

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.

Generic OPL2/OPL3 FM synthesizer support?

Answer "y" if your card has a FM chip made by Yamaha (OPL2/OPL3/OPL4). Answering "y" is usually a safe and recommended choice, however some cards may have software (TSR) FM emulation. Enabling FM support with these cards may cause trouble (I don't currently know of any such cards, however).

Gravis Ultrasound support?

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.

MPU-401 support (NOT for SB16)?

Be careful with this question. The MPU401 interface is supported by almost all soundcards. However, some natively supported cards have their own driver for MPU401. Enabling the MPU401 option with these cards will cause a conflict. Also enabling MPU401 on a system that doesn't really have a MPU401 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 MPU401 MIDI interface card.

6850 UART Midi support?

It's safe to answer "n" to this question in all cases. The 6850 UART interface is very rarely used.

PSS (ECHO-ADI2111) support?

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).

16 bit sampling option of GUS (not GUS MAX)?

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.

GUS MAX support?

Answer "y" only if you have a GUS MAX.

Microsoft Sound System support?

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.

Ensoniq Soundscape support?

Answer "y" if you have a soundcard based on the Ensoniq SoundScape chipset. Such cards are being manufactured at least by Ensoniq, Spea and Reveal (Reveal makes other cards also).

MediaTriX AudioTriX Pro support?

Answer "y" if you have the AudioTriX Pro.

Support for MAD16 and/or Mozart based cards?

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).

SoundBlaster Pro support?

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.

SoundBlaster 16 support?

Enable if you have a SoundBlaster 16 (including the AWE32).

Audio Excel DSP 16 initialization support?

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.

/dev/dsp and /dev/audio support (usually required)?

Answering "n" disables /dev/dsp and /dev/audio, the A/D and D/A converter devices. Answer "y".

MIDI interface support?

Answering "n" disables /dev/midixx devices and access to any MIDI ports using /dev/sequencer and /dev/music. This option also affects any MPU401 and/or General MIDI compatible devices.

FM synthesizer (YM3812/OPL-3) support?

Answer "y" here.

/dev/sequencer support?

Answering "n" disables /dev/sequencer and /dev/music

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.

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.

4.3 Creating the Device Files

The first time the kernel sound driver is configured you need to create the sound device files. The easiest way to do this is to cut the short shell script from the end of the file Readme.linux in the directory /usr/src/linux/drivers/sound, and run it as user root.

If your device entries already exist, you might want to ensure they are correct. If they are not, or if you are in doubt, run the above script and it will replace any existing entries with correct ones.

Some older Linux distributions provided install scripts which created incorrect sound device files. You may also have a /dev/MAKEDEV script for creating device files. Using the script included with the kernel sound driver is preferred since it should always be up to date with the latest supported sound devices.

After running the script your sound device files should look something like this:

lrwxrwxrwx   1 root        11 Aug 22 00:01 audio -> /dev/audio0
crw-rw-rw-   1 root   14,   4 Aug 22 00:01 audio0
crw-rw-rw-   1 root   14,  20 Aug 22 00:01 audio1
lrwxrwxrwx   1 root         9 Aug 22 00:01 dsp -> /dev/dsp0
crw-rw-rw-   1 root   14,   3 Aug 22 00:01 dsp0
crw-rw-rw-   1 root   14,  19 Aug 22 00:01 dsp1
crw-rw-rw-   1 root   14,   2 Aug 22 00:01 midi00
crw-rw-rw-   1 root   14,  18 Aug 22 00:01 midi01
crw-rw-rw-   1 root   14,  34 Aug 22 00:01 midi02
crw-rw-rw-   1 root   14,  50 Aug 22 00:01 midi03
crw-rw-rw-   1 root   14,   0 Aug 22 00:01 mixer
crw-rw-rw-   1 root   14,  16 Aug 22 00:01 mixer1
crw-rw-rw-   1 root   14,   8 Aug 22 00:01 music
crw-rw-rw-   1 root   14,  17 Aug 22 00:01 patmgr0
crw-rw-rw-   1 root   14,  33 Aug 22 00:01 patmgr1
crw-rw-rw-   1 root   14,   1 Aug 22 00:01 sequencer
lrwxrwxrwx   1 root        10 Aug 22 00:01 sequencer2 -> /dev/music
crw-rw-rw-   1 root   14,   6 Aug 22 00:01 sndstat

If you are using the PC speaker sound driver, read the documentation that came with the package to determine what device files to create.

Normally the configuration you used when building the kernel will be acceptable to the sound card driver. It is also possible to pass parameters on the kernel command line (e.g. from LILO) to configure the sound driver. These are defined in the file Readme.linux. It should rarely be necessary to use these. They are mainly intended for developers of Linux boot disks to create a kernel that supports multiple types of sound cards.

4.4 Booting Linux and Testing the Installation

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):

snd2 <SoundBlaster Pro 3.2> at 0x220 irq 5 drq 1
snd1 <Yamaha OPL-3 FM> at 0x388 irq 0 drq 0

This should match your sound card type and jumper settings (if any).

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
VoxWare Sound Driver:3.0.1-950812 (Thu Aug 17 23:33:07 EDT 1995 root@fizzbin.ca)
Config options: 312002

Installed drivers: 
Type 1: OPL-2/OPL-3 FM
Type 2: SoundBlaster

Card config: 
SoundBlaster at 0x220 irq 5 drq 1
OPL-2/OPL-3 FM at 0x388 irq 0 drq 0

Audio devices:
0: SoundBlaster Pro 3.2

Synth devices:
0: Yamaha OPL-3

Midi devices: NOT ENABLED IN CONFIG

Timers:
0: System Timer

Mixers:
0: SoundBlaster

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).

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
% 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

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.

4.5 Troubleshooting

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.

Step 1: Make sure you are really running the kernel you compiled.

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 1.3.20 #1 Fri Aug 18 22:12:36 EDT 1995 i386

or by displaying the file /proc/version:

% cat /proc/version
Linux version 1.2.13 (root@fizzbin) (gcc version 2.6.3) #9 Sun Aug 6 11:56:47 EDT 1995

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?

Step 2: Make sure the kernel sound drivers are compiled in.

You can see what drivers are compiled in by looking at /proc/devices:

% cat /proc/devices
Character devices:
 1 mem
 4 tty
 5 cua
 6 lp
14 sound
15 Joystick

Block devices:
 2 fd
 3 hd
25 sbpcd

What we are looking for here is character device 14, labeled "sound". If the sound device is not listed then something went wrong with the kernel configuration or build. Start the installation process again, beginning with configuration and building of the kernel.

Step 3: Did the kernel detect your sound card during booting?

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.

Step 4: Can you read data from the dsp device?

Try reading from the /dev/audio device using the dd command listed earlier in this document. The command should run without errors.

If this does not work, then a possible cause is the device file. Make sure than the device files in the /dev directory has the correct major and minor numbers as listed previously. Check that the permissions on the device file allow reading and writing.

A remote possibility is a hardware problem. Try testing the drive under DOS, if possible, to determine if this could be the case.

When All Else Fails

If you still have problems, here are some final suggestions for things to try:


Previous Next Contents