1. Determine what device driver module supports your sound board. The best place to start looking for information is in the Linux HOWTOs. The most up-to-date copies are kept at http://sunsite.unc.edu/LDP/, but relatively current copies of these documents are usually included with CD-ROM distributions.
2. Determine the device addresses for your audio card. The easiest way to do this on a dual-boot Windows 95/Linux machine is to look up the audio card in the device manager to get the interrupt and IO addresses. Barring that, it is possible to configure Plug and Play devices as discussed in the next section.
3. Using your favorite text editor, edit the /etc/conf.modules file. Make sure you have a backup of this file somewhere so you can restore it in case things go wrong. My /etc/conf.modules looks like this:
alias eth0 ne
options ne io=0xe000 irq=12
alias scsi_hostadapter ppa
options ppa ppa_nybble=0
alias sound sb
The key element here is the line alias sound sb. In this case, the init scripts included with Linux look for the sound alias in the /etc/conf.modules file and, if they find it, load the sound modules. In this case, the defaults work fine. The modules attempt to find the sound card, and in the case of common hardware, everything will work just fine.
4. If you (or the sound card’s configuration program) have set the configuration to non-default settings, you might need to specify these when adding your sound card. Generally, the IO address, IRQ(s), and DMA channels must be specified. The following example tells the SoundBlaster driver to look for the card at the factory default values:
alias sound sb
options sound ioaddr=220 irq=5 dma=1,5
This tells the driver to look for the SoundBlaster card at IO address 220, interrupt 5, and using DMA channels 1 and 5. For 8-bit SoundBlaster and SoundBlaster Pros, only one 8-bit DMA channel is required.
Determining the device driver module for your sound card
Determining what device driver module supports your sound card can take quite a bit of time because there is a lot of documentation to wade through for some of the weirder configurations. The Creative Labs’ ubiquitous SoundBlaster series is well supported, and can even be made to work without recompiling the kernel. Even the cheaper Opti and Crystal audio chipsets can be made to work with some effort, but these are the cards in which it’s best to combine all the drivers you need into one module.
Using sndconfig to configure SoundBlaster cards
If you have a SoundBlaster, SoundBlaster Pro, SoundBlaster 16, 16 Pnp, AWE 32, or AWE 64 sound card, you can use /usr/sbin/sndconfig to configure Plug and Play and the sound modules for you. Although these are the only cards sndconfig officially supports, you can use sndconfig to gain insight into how sound configuration works by looking over the output files (that is, the changes to /etc/conf.modules and /etc/isapnp.conf files). If all this works for you and your SoundBlaster card, you can stop reading this section right now…
Plug and Play Devices
ISA Plug and Play hardware is becoming more and more common. Although it is a common myth that only Windows 95 supports Plug and Play devices, PCI devices are inherently Plug and Play, and are managed (for the most part) by your PC BIOS with little operating system intervention. ISA Plug and Play is another matter altogether because the ISA bus predates the Plug and Play standard by more than a few years. Most people mean ISA Plug and Play when they utter the words Plug and Play.
Linux can be made to work with ISA Plug and Play devices. The first tool that can be used to make Plug and Play devices work with Linux is your system’s BIOS. Most PC BIOSes have a setting to indicate whether a Plug and Play operating system is installed. Changing the setting to No often causes the BIOS to activate all ISA Plug and Play devices before booting the system. This means that, for the most part, these devices act as regular jumpered devices.
Some BIOSes, however, either do not have this capability, or don’t support the correct Plug and Play specification. There are two specifications: the Intel one, and the Microsoft one. Each is somewhat compatible with the other, but more so in theory than in practice. If this is the case for you, all is not lost.
One ISA Plug and Play utility for Linux can be used to activate ISA Plug and Play devices. There is a good Web page that describes the process in greater detail, as well as links to the software, at http://www.redhat.com/linux-info/pnp/.
The system will use PnP if it finds a configuration file
Red Hat’s init scripts actually look for the PnP package’s configuration files, and automatically call the program to configure the hardware for you if the program is installed according to specifications.
Managing Modules
Most modules on your system are managed by kerneld, but there are times during which manual intervention is required. One limitation is having multiple SCSI adapters of different types in the system. The main SCSI adapter is in the conf.modules’ scsi_hostadapter alias, but since kerneld allows only one SCSI setting in the conf.modules file, you have a problem. The answer is not overly complicated—the additional SCSI adapter must be managed manually. This is not as big of a deal as it seems, since the SCSI driver can be loaded with one command and then left in memory. In most cases, this is a parallel port SCSI device anyway, such as a Zip drive.
Other circumstances can occur where it is more convenient to manage modules manually. Sound driver modules should be tested by manually loading and unloading them, rather than immediately configuring them into the /etc/modules.conf file.
Installing Modules
To load a module manually from the command line, log on as root and issue the following command:
/sbin/modprobe <module-name>
In this case, <module-name> is the name of the module you want to install (for instance, use ppa to install the Zip driver module). modprobe reads its configuration from /etc/conf.modules as well, and it accepts aliases as well as real module names on the command line.
If you’re logged on as root
If you have logged on as root rather than having su’d from a user account, you can leave out the /sbin at the beginning of the command.