Configuring and building the kernel is covered elsewhere in this book. We cover here a few points relevant to multimedia . As mentioned earlier, most multimedia cards use the PCI bus and should be automatically detected and configured by the Linux kernel.
9.2.1. Sound Drivers
The history of sound drivers under Linux deserves some mention here, because it helps explain the current diversity in offerings. Early in the development of Linux (i.e., before the 1.0 kernel release), Hannu Savolainen implemented kernel-level sound drivers for a number of popular sound cards. Other developers also contributed to this code, adding new features and support for more cards. These drivers, part of the standard kernel release, are sometimes called OSS/Free, the free version of the Open Sound System .
Hannu later joined 4Front Technologies , a company that sells commercial sound drivers for Linux as well as a number of other Unix-compatible operating systems. These enhanced drivers are sold commercially as OSS/4Front.
In 1998 the Advanced Linux Sound Architecture, or ALSA project, was formed with the goal of writing new Linux sound drivers from scratch, and to address the issue that there was no active maintainer of the OSS sound drivers. With the benefit of hindsight and the requirements for newer sound card technology, the need was felt for a new design.
Some sound card manufacturers have also written Linux sound drivers for their cards, most notably the Creative Labs Sound Blaster Live! series.
The result is that there are as many as four different sets of kernel sound drivers from which to choose. This causes a dilemma when choosing a sound driver. Table 9-1 summarizes some of the advantages and disadvantages of the different drivers, in order to help you make a decision. Another consideration is that your particular Linux distribution will likely come with one driver, and it will be more effort on your part to use a different one.
In addition to the drivers mentioned in Table 9-1, kernel patches are sometimes available that address problems with specific sound cards.
The vast majority of sound cards are supported under Linux by one driver or another. The devices that are least likely to be supported are very new cards, which may not yet have had drivers developed for them, and some high-end professional sound cards , which are rarely used by consumers. You can find a reasonably up-to-date list of supported cards in the current Linux Sound HOWTO document, but often the best solution is to do some research on the Internet and experiment with drivers that seem likely to match your hardware.
Many sound applications use the kernel sound drivers directly, but this causes a problem: the kernel sound devices can be accessed by only one application at a time. In a graphical desktop environment, a user may want to simultaneously play an MP3 file, associate window manager actions with sounds, be alerted when there is new email, and so on. This requires sharing the sound devices between different applications. To address this, modern Linux desktop environments include a sound server that takes exclusive control of the sound devices and accepts requests from desktop applications to play sounds, mixing them together. They may also allow sound to be redirected to another computer, just as the X Window System allows the display to be on a different computer from the one on which the program is running. The KDE desktop environment uses the artsd sound server, and GNOME provides esd. Because sound servers are a somewhat recent innovation, not all sound applications are written to support them yet. You can often work around this problem by suspending the sound server or using a wrapper program such as artswrapper, which redirects accesses to sound devices to go to the sound server.
126.96.36.199. Installation and configuration
In this section we discuss how to install and configure a sound card under Linux.
The amount of work you have to do depends on your Linux distribution. As Linux matures, some distributions are now providing automatic detection and configuration of sound cards. The days of manually setting card jumpers and resolving resource conflicts are becoming a thing of the past as sound cards become standardized on the PCI bus. If you are fortunate enough that your sound card is detected and working on your Linux distribution, the material in this section won't be particularly relevant because it has all been done for you automatically.
Some Linux distributions also provide a sound configuration utility such as sndconfig that will attempt to detect and configure your sound card, usually with some user intervention. You should consult the documentation for your system and run the supplied sound configuration tool, if any, and see if it works.
If you have an older ISA or ISA PnP card, or if your card is not properly detected, you will need to follow the manual procedure we outline here. These instructions also assume you are using the OSS/Free sound drivers. If you are using ALSA, the process is similar, but if you are using commercial drivers (OSS/4Front or a vendor-supplied driver), you should consult the document that comes with the drivers, because the process may be considerably different.
The information here also assumes you are using Linux on an x86 architecture system. There is support for sound on other CPU architectures, but not all drivers are supported and there will likely be some differences in device names and other things.
188.8.131.52. Collecting hardware information
Presumably you already have a sound card installed on your system. If not, you should go ahead and install one. If you have verified that the card works with another operating system on your computer, that will assure you that any problem you encounter on Linux is caused by software at some level.
You should identify what type of card you have, including manufacturer and model. Determine if it is an ISA, ISA PnP , or PCI card. If the card has jumpers, you should note the settings. If you know what resources (IRQ, I/O address, DMA channels) the card is currently using, note that information as well.
If you don't have all this information, don't worry. You should be able to get by without it; you just may need to do a little detective work later. On laptops or systems with on-board sound hardware, for example, you won't have the luxury of being able to look at a physical sound card.
184.108.40.206. Configuring ISA Plug and Play (optional)
Modern PCI bus sound cards do not need any configuration. The older ISA bus sound cards were configured by setting jumpers. ISA PnP cards are configured under Linux using the ISA Plug and Play utilities. If you aren't sure if you have an ISA PnP sound card, try running the command pnpdump and examining the output for anything that looks like a sound card. Output should include lines like the following for a typical sound card:
# Card 1: (serial identifier ba 10 03 be 24 25 00 8c 0e) # Vendor Id CTL0025, Serial Number 379791851, checksum 0xBA. # Version 1.0, Vendor version 1.0 # ANSI string -->Creative SB16 PnP<--
The general process for configuring ISA PnP devices is as follows:
Most modern Linux distributions take care of initializing ISA PnP cards. You may already have a suitable /etc/isapnp.conf file, or it may require some editing.
For more details on configuring ISA PnP cards, see the manpages for isapnp, pnpdump, and isapnp.conf and read the Plug-and-Play HOWTO from the Linux Documentation Project.
220.127.116.11. Configuring the kernel (optional)
In the most common situation, where you are running a kernel that was provided during installation of your Linux system, all sound drivers should be included as loadable modules and it should not be neccessary to build a new kernel.
You may want to compile a new kernel if the kernel sound driver modules you need are not provided by the kernel you are currently running. If you prefer to compile the drivers directly into the kernel rather than use loadable kernel modules , a new kernel will be required as well.
See Chapter 18 for detailed information on rebuilding your kernel.
18.104.22.168. Configuring kernel modules
In most cases the kernel sound drivers are loadable modules, which the kernel can dynamically load and unload. You need to ensure that the correct drivers are loaded. You do this using a configuration file, such as /etc/conf.modules. A typical entry for a sound card might look like this:
alias sound sb alias midi opl3 options opl3 io=0x388 options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
You need to enter the sound driver to use and the appropriate values for I/O address, IRQ, and DMA channels that you recorded earlier. The latter settings are needed only for ISA and ISA PnP cards because PCI cards can detect them automatically. In the preceding example, which is for a 16-bit Sound Blaster card, we had to specify the driver as sb in the first line, and specify the options for the driver in the last line.
Some systems use /etc/modules.conf and/or multiple files under the /etc/modutils directory, so you should consult the documentation for your Linux distribution for the details on configuring modules. On Debian systems, you can use the modconf utility for this task.
In practice, usually the only tricky part is determining which driver to use. The output of pnpdump for ISA PnP cards and lspci for PCI cards can help you identify the type of card you have. You can then compare this to documentation available either in the Sound HOWTO or in the kernel source, usually found on Linux systems in the /usr/src/linux/Documentation/sound directory.
For example, a certain laptop system reports this sound hardware in the output of lspci:
00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
For this system the appropriate sound driver is cs46xx. Some experimentation may be required, and it is safe to try loading various kernel modules and see if they detect the sound card.
22.214.171.124. Testing the installation
The first step to verify the installation is to confirm that the kernel module is loaded. You can use the command lsmod; it should show that the appropriate module, among others, is loaded:
$ /sbin/lsmod Module Size Used by parport_pc 21256 1 (autoclean) lp 6080 0 (autoclean) parport 24512 1 (autoclean) [parport_pc lp] 3c574_cs 8324 1 serial 43520 0 (autoclean) cs46xx 54472 4 soundcore 3492 3 [cs46xx] ac97_codec 9568 0 [cs46xx] rtc 5528 0 (autoclean)
Here the drivers of interest are cs46xx, soundcore, and ac97_codec. When the driver detected the card, the kernel should have also logged a message that you can retrieve with the dmesg command. The output is likely to be long, so you can pipe it to a pager command, such as less:
PCI: Found IRQ 11 for device 00:05.0 PCI: Sharing IRQ 11 with 00:02.0 PCI: Sharing IRQ 11 with 01:00.0 Crystal 4280/46xx + AC97 Audio, version 1.28.32, 19:55:54 Dec 29 2001 cs46xx: Card found at 0xf4100000 and 0xf4000000, IRQ 11 cs46xx: Thinkpad 600X/A20/T20 (1014:0153) at 0xf4100000/0xf4000000, IRQ 11 ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Cirrus Logic CS4297A rev B)
For ISA cards, the device file /dev/sndstat shows information about the card. This won't work for PCI cards, however. Typical output should look something like this:
$ cat /dev/sndstat OSS/Free:3.8s2++-971130 Load type: Driver loaded as a module Kernel: Linux curly 2.2.16 #4 Sat Aug 26 19:04:06 PDT 2000 i686 Config options: 0 Installed drivers: Card config: Audio devices: 0: Sound Blaster 16 (4.13) (DUPLEX) Synth devices: 0: Yamaha OPL3 MIDI devices: 0: Sound Blaster 16 Timers: 0: System clock Mixers: 0: Sound Blaster
If these look right, you can now test your sound card. A simple check to do first is to run a mixer program and verify that the mixer device is detected and that you can change the levels without seeing any errors. Set all the levels to something reasonable. You'll have to see what mixer programs are available on your system. Some common ones are aumix, xmix, and KMix.
Now try using a sound file player to play a sound file (e.g., a WAV file) and verify that you can hear it play. If you are running a desktop environment, such as KDE or GNOME, you should have a suitable media player; otherwise, look for a command-line tool such as play.
If playback works, you can then check recording. Connect a microphone to the sound card's mic input and run a recording program, such as rec or vrec. See whether you can record input to a WAV file and play it back. Check the mixer settings to ensure that you have selected the right input device and set the appropriate gain levels.
You can also test whether MIDI files play correctly. Some MIDI player programs require sound cards with an FM synthesizer, others do not. Some common MIDI players are Playmidi, KMid, and KMidi. Testing of devices on the MIDI bus is beyond the scope of this book.
A good site for general information on MIDI and MIDI devices is http://midistudio.com. The official MIDI specifications are available from the MIDI Manufacturers Association. Their web site can be found at http://www.midi.org.
9.2.2. Video Drivers
When configuring the Linux kernel, you can enable a number of video -related options and drivers . Under the Multimedia Drivers section, you can configure VideoForLinux, which has support for video capture and overlay devices and radio tuner cards. Under the Graphics Support category, you can enable frame buffer support for various video cards so that applications can access the video hardware via the kernel's standardized frame buffer interface. For more information on building the kernel, see Chapter 18.
Your X server also needs support for your video hardware. The X windowing system software provided by your distribution vendor should have included all of the open source drivers . There may also be closed-source drivers available for your video card from the manufacturer. If these are not included in your distribution, you will have to obtain and install them separately. For more information on the X Window System, see Chapter 16.
9.2.3. Alternate Input Devices
When configuring the kernel, under the Input Device Support section you can enable support for various specialized mouse drivers, joysticks, and touchscreens.
For scanners and digital cameras, the kernel just needs to support the interface type that the devices use (serial, SCSI, USB, etc.). Communicating with the actual device will be done by applications or libraries such as SANE or libgphoto2.