Chapter 8. Hardware Support

Table of Contents

Introduction
ALSA - Advanced Linux Sound Architecture
Installing ALSA
Basic ALSA Configuration
Keeping your Changes
Using Sound Servers
CUPS - former "Common Unix Printing System"
Installing CUPS
Configuring CUPS
Managing Device Files
Further Resources

Introduction

Some hardware is automatically enabled once you have configured it inside the Linux kernel: access to PCI chip sets, graphical card, disks, USB storage, etc. Yet, most hardware requires additional work. After all, the Linux kernel provides you with a programmatic interface to access the devices, but you still need the necessary tooling to get the device to function properly. Good examples are network cards and printers, but also sound cards.

ALSA - Advanced Linux Sound Architecture

ALSA is an open source project that provides audio functionality to the Linux kernel. It supports professional audio hardware (next to the consumer audio hardware, including sound cards) and provides a powerful, standard interface which allows, for instance, multiple software access to a single audio device. For programmers, ALSA's API is well documented and you'll quickly find that the ALSA library provides thread-safe access to the device(s).

The project also provides tools to manage the audio devices such as a simple mixer program (alsamixer), modular sound drivers which allow users to fine-tune the drivers' configuration aspects and of course support for the older OSS/Free implementation (Linux' previous open sound system).

Installing ALSA

Installing ALSA consists of two distinct steps:

  1. Configure the Linux kernel with ALSA support and with support for your sound card(s)

  2. Install the ALSA utilities

If you configure your kernel, you can either opt to install the sound card drivers in your kernel or as a kernel module. ALSA's configuration utility (alsaconf) assumes that you use kernel modules for your sound cards. However, this is not a requirement - you can still configure ALSA sound card drivers if they are built inside the kernel. The interface to do so however is a bit more complex.

To install the ALSA utilities, it is sufficient to emerge alsa-utils:

# emerge alsa-utils

Basic ALSA Configuration

The basic ALSA configuration starts with detecting your sound card and enabling the channels on it (sound channels) as ALSA will, by default, mute the channels (this is for precautionary reasons - you don't want to blow your speakers the first time you launch your computer do you?).

The first part (detecting the sound card) can be done using alsaconf. The alsaconf tool will attempt to detect your sound card(s), load the necessary modules and configure those with sane settings. It will save whatever it found to a general file which is read by your favourite distribution (which is undoubtedly Gentoo ;-) at start up so you don't have to rerun alsaconf after every boot.

# alsaconf

With your sound card(s) detected, launch alsamixer to view the available channels. The alsamixer tool will show you all channels associated with your sound card. You will find that, by default, all channels are muted. Unmute them, but bring the volume of the channels to a safe setting. Don't worry, you can increase them whenever you want later.

# alsamixer

Inside alsamixer, you can

  • move from one channel to the other with the arrow keys (left/right)

  • increase/decrease the volume of each channel with the arrow keys (up/down)

  • mute/unmute the channel using the 'M' key

  • exit the application using the Escape key (or Alt+Q)

If your sound card has particular features you can't seem to find inside the mixer application, you will need to turn to the alsactl command. The alsactl utility supports multiple devices and allows you to tweak every supported feature of your sound card. Its interface is quite simple: use alsactl to dump the sound card information to a file, then edit the file to your likings. Once finished, use alsactl to read the (modified) file back.

# alsactl -f /path/to/asound.state store
(Now edit /path/to/asound.state)
# alsactl -f /path/to/asound.state restore

If you have changed the file to such an extend that you can't get the sound to work again, you can re-initialize the settings using alsactl init.

Finally, if you have multiple devices, use a sequence number to identify them. You can find your list of numbers in /proc/asound/cards:

$ cat /proc/asound/cards
 0 [ICH6           ]: ICH4 - Intel ICH6
                      Intel ICH6 with Cx20468-31 at irq 17

The number (I only have one card, so mine is 0) can then be passed on to the various alsa utilities, like so:

$ alsamixer -c 0

Keeping your Changes

When you booted your system, you unmuted the channels and set the mixer channels according to your likings. However, if you do nothing more now, you'll have to redo all this again after every boot. To solve this, you need to store the current settings in a state file (yes, using alsactl) and automatically read those in at boot time.

This is exactly what the alsasound init script does (as provided by Gentoo's alsa-utils package). So, add alsasound to your boot runlevel, save your current settings and then start the initialization script:

# rc-update add alsasound boot
# alsactl -f /var/lib/alsa/asound.state store
# /etc/init.d/alsasound start

Using Sound Servers

I mentioned before that ALSA supports multiple software access to a single device. With the above configuration, you're still not able to do so. To provide such multiplexing capabilities, you can create a new audio device (some sort of mixer) which aggregates information to/from the device and sends/reads it from as many software processes as you like.

This is one of the tasks that sound servers do: these programs manage access to the sound card (interfaces) and allow multiple software processes to use the sound facilities of your system. Some well known sound servers are JACK and PulseAudio.

  • JACK (JACK Audio Connection Kit) is a real-time sound server which supports various operating systems (including GNU/Linux and Apple's OS X). It also supports network-transparent audio, real-time mixing, etc.

  • PulseAudio (PulseAudio) is another sound daemon. It is a replacement for the Enlightened Sound Daemon, an older sound server project, but has a much wider support field (including Microsoft Windows and POSIX-compliant operating systems).

If you'd like to use one of these sound servers (you do need to pick one if you don't want to get confused), install one of the following packages:

  • JACK can be installed with media-sound/jack

  • PulseAudio can be installed from media-sound/pulseaudio.

Enable the corresponding USE flag (jack or pulseaudio) and update your system. Portage will automatically rebuild those packages that are influenced by the USE flag change and incorporate support for the selected sound daemon in those packages:

# nano -w /etc/portage/make.conf
(Edit USE, add the appropriate USE flag)
# emerge --update --deep --newuse @world

You can also ask euse which packages are affected by a USE flag change:

# euse -I pulseaudio

If you want to know which packages all use a specific USE flag (even uninstalled packages), use euse -i:

# euse -i pulseaudio

CUPS - former "Common Unix Printing System"

If you need to connect your Linux system to a printer, using the CUPS tool is advised. With CUPS you can both connect to locally attached printers (USB, LPT) as well as remote (through Windows sharing or IPP). You can also use CUPS to build a print server yourself, although this is definitely outside the scope of this book.

Installing CUPS

Before you start installing the software, you will first need to make sure that your kernel configuration supports the printer:

  • for locally attached printers using the (old) LPT interface, look for "Parallel port support -> PC-style hardware" and "Parallel printer support -> IEEE 1284 transfer modes")

  • for locally attached printers using the USB interface, look for "USB Printer support" (as well as all other USB-required settings such as one of the xHCI supports)

  • for remote printers using the Windows sharing (SMB-CIFS protocol), look for "Network File Systems -> SMB file system support" and "CIFS support")

  • for remote printers using the IPP protocol, you generally do not need to enable any additional settings in the kernel

If you notice that you have not selected the right configuration yet, you'll need to rebuild the kernel and reboot (see our chapter on "Configuring a Linux Kernel").

Next, install the net-print/cups package, making sure you select the correct USE flags (this is discussed in a different chapter).

~# emerge net-print/cups

Don't worry if you do not have all USE flags correct from the first run. As I will mention later, it is always possible to update USE flags afterwards and then have Gentoo rebuild those packages affected by that change.

If your printer is locally attached, you need to start the CUPS service:

~# /etc/init.d/cupsd start

Also, make sure it is started upon every (re)boot:

~# rc-update add cupsd default

Configuring CUPS

CUPS offers a web interface to configure CUPS (and configure your printer). You can reach it through http://localhost:631. In the Administration page, enter your root login and password information and you can get started with the configuration. The Gentoo Printing article offers great resources and walk throughs of the configuration.

You probably hoped for a more elaborate discussion on printer configuration. Perhaps in the far future I will discuss printer configuration more, but for the time being I'm going to limit this and refer to Gentoo's guide and the main CUPS site.

Managing Device Files

Almost every device on your system is represented by a device file. The udev device manager discovers attached devices, creates device files in /dev (yes, you can create them - take a look at the mknod manpage) and often also creates symbolic links to those device files so you can find the correct device file more easily.

The udev tool receives events from the Linux kernel; the moment such an event is received, udev matches the device attributes as offered by sysfs (you can browse through /sys if you want to see what sysfs offers) against a set of rules. These rules you can view at /lib/udev/rules.d (provided by the udev distribution) and /etc/udev/rules.d (provided by third-party packages and, of course, your own rules if you write them yourself).

Gentoo offers a set of default rules which should be sufficient for most users. For instance, they create links to the (removable) disks inside /dev/disk/by-id, by-path and by-uuid, which should allow you to have a device link for fstab which will be the same regardless of when you plug it in (in case of a hot pluggable device, of course). This is important, because if you have, for instance, two USB storage devices, the order in which they are plugged in defines the /dev/sd* device naming. By using the links at /dev/disk/by-* you can make sure that the correct device is targeted.

Further Resources