Table of Contents
Some hardware is automatically enabled once you have configured it inside the Linux kernel: access to PCI chipsets, graphical card, disks, USB storage, etc. Yet, most hardware requires additional work. After all, the Linux kernel provides you with a programmatical 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 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 consists of two distinct steps:
Configure the Linux kernel with ALSA support and with support for your sound card(s)
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-utilsThe 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 favorite distribution (which is undoubtedly Gentoo ;-) at start up so you don't have to rerun alsaconf after every boot.
# alsaconfWith 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.
# alsamixerInside 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 17The number (I only have one card, so mine is 0) can then be passed on to the various alsa utilities, like so:
$ alsamixer -c 0When 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
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 esd, aRTs (deprecated), JACK and PulseAudio.
esd (Enlightenment Sound Daemon) is GNOME's sound management daemon. esd, also known as ESounD, not only supports the abovementioned mixing, but can also manage network-transparent audio: audio played on one system can be heard on another. To this end, any application supporting esd can stream its audio to any system running esd on the network.
aRTs (Analog RealTime Synthesizer) is KDE's former sound daemon. Although development has been abandoned, you will still find references to aRTs here and there on the Internet. Its main power was its real-time audio streaming capabilities.
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 meant to be a replacement for esd but with a 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:
esd can be installed from media-sound/esound, although most people will already have it installed if they are running GNOME (it is a dependency of the GNOME installation)
JACK can be installed with media-sound/jack
PulseAudio can be installed from media-sound/pulseaudio.
Enable the corresponding USE flag (esd, 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/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 pulseaudioIf you want to know which packages all use a specific USE flag (even uninstalled packages), use euse -i:
# euse -i pulseaudioIf 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.
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/cupsDon'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/cups startAlso, make sure it is started upon every (re)boot:
~# rc-update add cups defaultCUPS 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 HOWTO offers a great walkthrough 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.
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.
Gentoo ALSA Guide, an excellent resource on configuring ALSA within Gentoo.
Writing udev rules, written by Daniel Drake
Gentoo Printing HOWTO, another excellent resource by Gentoo, now on printer configuration.