On the ALSA Track
On the ALSA Web site, you read that ALSA stands for the Advanced Linux Sound Architecture. Normal users normally don't think about such things as sound architectures, so before I say more about ALSA and why it's advanced, I must present a brief description and history of the Linux sound architecture.
A sound architecture may provide a variety of audio-related functions, but it must include at least a low-level connection between the soundcard driver and kernel services and a higher-level audio software programming interface to simplify applications development. Until the 2.5.x development track, the Linux kernel utilized an audio API now known as OSS/Free. OSS here stands for Open Sound System, an audio API originally written in 1992 by Hannu Savolainen. Independent developers contributed drivers and other work to the OSS/Free system, but by the late 1990s the OSS API was showing its age. Around that time, a Czech system administrator named Jaroslav Kysela began work on what eventually became the ALSA project. Like Linux itself, ALSA began with rather modest goals: Jaroslav simply wanted more out of his Gravis UltraSound soundcard than the existing API could deliver, and he was willing and able to meet the demands of the task. Like Linus Torvalds, Jaroslav eventually found himself at the center of a group of talented developers, all dedicated to the development of a superior audio API for Linux.
ALSA's features and popularity grew to a point when users and developers began lobbying for utilizing ALSA to replace the OSS/Free system packaged with the kernel sources. Testing began with the 2.5.x development kernels, and from the 2.6.x kernels onward ALSA has been the default Linux sound architecture.
As mentioned, ALSA's developers have concerned themselves with designing a truly superior sound system for Linux. On the ALSA Web site we read this description of the project's most significant features:
Efficient support for all types of audio interfaces, from consumer soundcards to professional multichannel audio interfaces.
Fully modularized sound drivers.
SMP and thread-safe design.
User space library to simplify application programming and provide higher level functionality.
Support for the older OSS/Free API, providing binary compatibility for most OSS/Free programs.
Licensed under the GPL and the LGPL.
This article is not intended to be a guide to installing or programming ALSA, nor does it describe every feature. I merely consider the features in the list above rather generally and briefly describe how I take advantage of ALSA on my own system.
For most normal users, perhaps the first and most important question is "Does ALSA support my soundcard ?" Linux support for audio hardware has been problematic due to the unwillingness of many manufacturers to provide either drivers or the specifications from which Linux drivers could be written. Notable exceptions have occurred, however, and by now ALSA supports many of the most popular soundcards and audio boards, including hardware from Creative Labs, RME and M-Audio. ALSA's driver support extends to serial and parallel port interfaces as well as to PCMCIA and USB hardware. ALSA even goes beyond hardware, providing a dummy driver and a most useful virtual MIDI driver. See the ALSA Soundcard Matrix for the current list of supported cards and chipsets.
Figure 1. The alsaconf Soundcard Configuration Utility
Mainstream Linux distributions try to identify and install the correct driver for your soundcard during the configuration stage of an initial installation. Usually a standalone sound configuration utility is included for tweaking beyond the original installation. ALSA provides alsaconf (see Figure 1), which is fine for simple card configurations, but it's not so good with systems having multiple cards, nor does it handle loading the virtual or dummy drivers. Fortunately, it's a simple matter to load and unload ALSA drivers (more about that in the following section).
I've used ALSA with quite a variety of soundcards. My current systems (desktop and laptop) enjoy ALSA support for an SBLive and a PCI128 on the desktop machine and a CS4232 audio chipset on my laptop. The external MIDI hardware is active on the soundcards, the EMU10k1 synthesizer is fully operational on the SBLive and both machines employ the virtual MIDI module. I also have a Core Sound PDAudio-CF PCMCIA card working nicely with the laptop and ALSA driver, giving me an excellent digital audio interface for that machine.
Similis sum folio de quo ludunt venti.
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems
Join editor Bill Childers and Bit9's Paul Riegle on April 27 at 12pm Central to learn how to keep your Linux systems secure.
Free to Linux Journal readers.Register Now!
|Security Hardening with Ansible||Aug 18, 2014|
|Monitoring Android Traffic with Wireshark||Aug 14, 2014|
|IndieBox: for Gamers Who Miss Boxes!||Aug 13, 2014|
|Non-Linux FOSS: a Virtualized Cisco Infrastructure?||Aug 11, 2014|
|Linux Security Threats on the Rise||Aug 08, 2014|
|Android Candy: Oyster—Netflix for Books!||Aug 07, 2014|
- Security Hardening with Ansible
- NSA: Linux Journal is an "extremist forum" and its readers get flagged for extra surveillance
- Monitoring Android Traffic with Wireshark
- Returning Values from Bash Functions
- IndieBox: for Gamers Who Miss Boxes!
- Why Python?
- RSS Feeds
- Tech Tip: Really Simple HTTP Server with Python
- Kernel Korner - Why and How to Use Netlink Socket
- Perceptions of the Linux OS Among Undergraduate System Administrators