From UnderLinux Wiki

Linux Soundcard Drivers - Uma introducao para usuarios e programadores [inglês]

In the Windows and Mac worlds, the end user rarely worries about drivers. Hardware manufacturers normally provide binaries, complete with installation utilities and other amenities (mixers, example programs, players, etc.), and updates are often available for free on the Internet. Alas, Linux does not yet enjoy the happy status of those worlds: manufacturers rarely supply native Linux drivers in any form, and Linux developers must often go to great efforts to write usable drivers for the manufacturer's hardware. Linux Soundcard Drivers: A brief guide for users and developers

by Dave Phillips 05/17/2001

Tabela de conteúdo 1 Introduction 2 Finding the Right Driver 3 The Kernel Modules 4 ALSA 5 OSS/Linux 6 Other Sources 7 What If ... 8 When All Else Fails... 9 Choosing a Driver 10 Boarding The Bus 10.1 ISA 10.2 Plug and Play 10.3 PCI 10.4 USB 10.5 Miscellany: PCMCIA Cards And Serial Port MIDI 11 The Linux Soundcard Driver 11.1 Finding and Installing Drivers 11.2 The Future of Linux Audio Driver Support 12 Acknowledgements

Introduction

Linux applications depend on drivers to enable communications between an application and a hardware device such as a printer, CD-ROM drive, or soundcard. A working Linux sound system can be thought of as a sandwich, with application software as the top slice of bread and sound hardware (soundcard and speakers) as the bottom slice. Sandwiched in the middle is the meat (at least, the meat of this article) -- the audio device control software or soundcard device driver.

A soundcard driver provides the communication interface between an application and the audio system hardware. The driver operates within a multistage process: an application requests audio services from the kernel, the kernel summons the appropriate driver module (e.g., /usr/lib/modules/2.4.0/sound/es1370.o for my SB PCI128) to communicate with the soundcard, and the driver manages the bit-level manipulations of the soundcard's audio chipset. The driver acts as a translator for commands received from an application (which generally doesn't care whether my soundcard is a SoundBlaster Live Platinum or a PAS16), turning them into the very hardware-specific commands unique to the actual card, i.e., if I want sound from my SB Live I must have a Linux-compatible SB Live device driver.

Since drivers are hardware-specific, it should come as no surprise that one of the most frequently asked questions in Linux discussion groups is "Where can I find a driver for my [insert card name here] soundcard ?!". This article will help answer that question and others regarding the somewhat obscure world of Linux audio device drivers: In "Finding and Installing Drivers," I'll direct you to the possible sources for the correct driver for your soundcard; I'll help you decide between the likely choices; and we'll look briefly at the various ways to install and configure a new driver. In "Inside the Driver," I'll describe and briefly analyze a Linux audio device driver; and I'll demonstrate a simple example of programming the soundcard device using the kernel sound API and the ALSA API. In "The Future of Linux Audio Driver Support," I'll offer an outlook for upcoming Linux support from audio manufacturers and provide online and print resources for further reading.

Let's start by taking a look at the various sources for Linux soundcard drivers.

The specific CPU architecture addressed throughout this article is the Intel x86 series (and its competition from AMD and Cyrix). My apologies to interested readers running other Linux systems, and I would be happy to hear of your experience if you are running Linux sound drivers on systems such as LinuxPPC and 64-bit machines.

Finding the Right Driver

Drivers for many soundcards and audio chipsets are included with the regular Linux kernel sources. More cards and more features are supported by the driver packages from ALSA and 4Front (OSS/Linux). These three are the main sources of Linux soundcard drivers. A few other independently maintained drivers are listed on the Linux Music and Sound Applications site, and a very few manufacturers offer native Linux drivers of their own making.

If you're lucky your soundcard was detected automatically by your distribution's hardware probe, and if you're even luckier the distribution will install and configure the correct driver for you. In many cases, your card may be correctly identified, but the configuration routine may prompt you for more information, so be sure to keep the card's documentation handy.

The Kernel Modules

If you plan to use the kernel sound driver, read the documentation in /usr/src/linux/Documentation/sound, or run one of the kernel configuration scripts ('make [config|menuconfig|xconfig]') and study the selections and help files in the sound configuration section. Kernel developer Alan Cox sporadically maintains Linux Sound System, an information page that includes a listing of cards and chipsets supported by the kernel modules; unfortunately, it is out of date and does not include information for the sound system in kernels beyond the 2.2.x series. More information about using the kernel modules is occasionally available on the linux.dev.sound newsgroup.

Most modern Linux distributions include sound configuration utilities for managing the kernel sound modules. Red Hat's sndconfig is a typical sound system utility, detecting PnP (Plug and Play) and PCI cards or presenting a list of supported cards if no card is detected. The user acknowledges or makes the proper selection, sndconfig responds by prompting for any special information, the user completes the configuration, and the utility plays a short soundfile to verify a successful installation. Similar sound configuration tools are found in the SuSE and Mandrake distributions. Check your distribution's documentation for the name of your sound system configuration utility, then run it to see if your card or chipset is listed.

ALSA

The ALSA project maintains a well-organized soundcard matrix with listings by vendor, product name, and chipset. The recommended ALSA driver is also indicated. If your card is listed in the matrix, you may want to try the ALSA driver. The ALSA project has many virtues, including a very active community of users and developers. The drivers are free and open source, and a wide variety of cards and chipsets are supported. Drivers, libraries, and utilities must be compiled and installed locally (which may require root privileges). Installation and configuration can be tricky at times, although I had no problems with the recent drivers for my SBLive Value and my SB PCI128. As it nears the 1.0 release ALSA is a fast-moving target, but I must emphasize that the user community is very active and helpful. If you have trouble with your ALSA setup, someone on the users mailing list should be able to lend a helping hand.

OSS/Linux

4Front Technologies maintains a list of soundcards and chipsets supported by the company's commercially available OSS/Linux drivers. Check that list to see if your card is included; if it is, you can try OSS/Linux by downloading 4Front's limited-time demo package. The drivers are binary-only (sorry, no source code here); you install them by using 4Front's excellent soundconf utility, a straightforward text-based program that lets you easily install and uninstall the drivers, enable and disable card capabilities, and manage complex multiple card setups.

Other Sources

Very few companies supply native Linux drivers for their soundcards, but the notable exception is Creative Labs. They have generously released the source code for their popular SBLive under the GPL, and development of a native driver has been steady and fruitful. Please see the Creative Open Source page for more information regarding the current availability and development status of the SBLive driver.

Aureal also ventured into the native Linux driver development world, supplying users with mixed binary/source drivers for their popular Vortex chipsets. Alas, Aureal no longer exists, though independent work on the drivers continues at the Linux Aureal Driver site on SourceForge.

The Zefiro ZA2 is a somewhat dated ISA digital audio card with some nice features, including the company's support for Linux driver developers. Peter Wahl has written a driver and control panel for the ZA2 available from his ZA2 Driver for Linux page. Peter has also written an alpha ZA2 driver for ALSA, but the current version is compatible only with the API for the ALSA 0.5.x release series.

What If ...

If your card is supported by one or another of the preceding sources, you should have little or no difficulty with the installation and configuration procedures. Things may become more difficult if your situation falls into one of these scenarios:

• You want to replace an existing card with a new one.

In this case, if you're lucky you can simply take out the old card, put in the new one, reboot and let your distribution's hardware probe detect the change in your system. However, your luck will depend on how well you do your initial homework, so check for Linux support before you purchase the new board (or any new hardware for a Linux system).

• You have a card you want to install, but you have no documentation for it.

This can usually be resolved by searching for a tech support section on the manufacturer's site. You may be able to order a new set of docs, or you might find an online manual. Failing either of those solutions, use Google or Deja search engines to find other people who own the same card and ask for assistance. Although it's unlikely to contain Linux-specific information, the card's documentation may contain everything you need to know in order to identify the correct Linux driver for your card. Many audio chipsets appear on a variety of differently named cards, and you should know the names of the audio chipset and the card itself. That information should be found in your card's documentation; if it isn't (or if you have no documentation), you must search the card for any product identification and to find what chipsets are used.

• You have a card installed but your present kernel has no sound support and you need to recompile it with the sound system enabled.

This scenario presents no real difficulty. Simply enable sound support during the kernel configuration and specify the correct driver module for your soundcard (if you want to use the kernel sound modules; make no selection if you intend to use the ALSA driver). Complete the kernel configuration and compiling process, reboot, then configure the sound system as needed.

• You can't get the performance you desire from the current driver and want to try another one.

This is potentially the trickiest scenario to manage. Each of the available driver packages maintains a different presence in your system startup and filesystem. If your existing driver is modular you can simply remove it from /lib/modules/linux-version/sound; however, if the driver is hardcoded into the kernel you will to recompile the kernel for modular sound support. You must have a kernel set up for modular sound if you want to use the ALSA drivers (just don't select any specific driver when configuring the kernel). The 4Front package installation routine can be directed to uninstall any kernel sound modules (but not ALSA modules) before installing OSS/Linux; a reboot is not required.

• You have a laptop/notebok, it has a soundchip, and you don't know much more than that.

Take a look at the Linux On Laptops and Sound Card Support for Linux with Laptops sites. Both indicate Linux sound support for specific laptops and chipsets; driver recommendations and configuration instructions can also be found on those pages. I was pleasantly surprised to see how many laptops and notebooks will work with Linux, but the surprise is mixed. Indeed, many laptops can be configured for Linux sound; unfortunately it can be a difficult and frustrating task. Nevertheless, Linux laptop sound support has seen great improvement in the last few years, and the recommended web sites keep up with the evolving status of Linux laptop and notebook audio support.

When All Else Fails...

If you've searched the documentation and databases for the kernel modules, ALSA, and OSS/Linux, then you've almost exhausted the possible sources for Linux audio drivers. A few other independently maintained drivers are listed on the Linux sound apps pages; failing all other possibilities, write to your soundcard's manufacturer, politely inquiring whether they have any plans for supporting Linux, or if they would be willing to provide Linux driver developers with the necessary specifications.

When all else fails, buy a different soundcard. Do some homework, research the resources I've already mentioned, then purchase a card known to work under Linux, with an easily available driver. You still might want to write to the manufacturer of your original card, adding (politely) that the lack of a Linux driver prompted your decision to purchase a different card.

Choosing a Driver

If you are planning for the simplest use of your sound hardware (CD audio, MP3 playback, streaming audio, etc.) and your card is supported, and you just don't want to work very hard at the system setup (or spend any money on it), you should try the driver modules supplied with the kernel. Most modern Linux distributions provide kernels prepared for dynamically adding and deleting precompiled modules. Some include autodetection routines that will automatically configure the sound system with the correct drivers at startup, while other distributions require root privileges to select, configure, and install the needed modules after the initial installation.

If your needs tend towards sophisticated desktop sound (high-end games, digital audio/video editing) or the professional side (multi-channel hard disk recording) you should consider either ALSA or OSS/Linux. Linux is slowly gathering support for digital audio cards suitable for professional audio applications. Specifications for these boards include multichannel digital record and playback, sampling rates exceeding 48 kHz, and advanced synchronization options. They are definitely not soundcards: they do not support an on-board synthesizer, MIDI I/O is not provided, and in some cases external ADC/DAC hardware is required. Linux-friendly professional-grade digital audio cards include the RME Hammerfall (and its relations) and the MIDIman Delta series; a driver for the Hammerfall is available from ALSA, drivers for the Delta cards are available from both ALSA and 4Front.

Boarding The Bus

If you look at the layout of your computer's motherboard you will notice connection traces running between the expansion card slots and the CPU. These connections form a path for data transfer between the CPU and your peripherals; that pathway is known as a bus. Buses come in different kinds and capabilities, and you may need to know something about your system's bus in order to match your soundcard with the correct driver.

ISA

Linux support for Industry Standard Interface (ISA) bus soundcards dates from Hannu Savolainen's original kernel driver (written in 1992) for the original 8-bit SoundBlaster. The ISA bus is not generally regarded as sufficiently fast enough for any but the most basic sound services, but if that's what you have then you'll be happy to note that the kernel modules, ALSA, and OSS/Linux all support soundcards made for the now outdated bus.

Plug and Play

Some Linux distributions detect so-called ISA "Plug and Play" (PnP) soundcards during the installation process. If yours did not, or if you're adding a PnP soundcard to your system, you must run the PnP tools pnpdump and isapnp to create and run a PnP configuration file for your soundcard (see the respective man pages for more information regarding the PnP utilities). PnP card detection may also be enabled in the kernel configuration, but the reader should be aware that some cards are more "Plug and Pray" than "Plug and Play", and that you may still need to run the PnP tools to correctly configure your card. Some PnP soundcards are supported by the kernel modules, but you'll find much wider support from the ALSA and OSS/Linux packages.

PCI

The Peripherals Component Interconnect (PCI) bus is considered fast enough for serious audio work, and PCI soundcards are currently the norm in modern desktop computers. PCI allows efficient two-way communication with the host CPU, so PCI soundcards are most easily probed and detected by the kernel and OSS/Linux setup utilities. As with the PnP cards, some PCI audio chipsets have driver modules included with the kernel sources, but again a much wider selection is available from ALSA and OSS/Linux. If you are compiling your own kernel you must be sure to enable PCI support in the section for IDE/ATA/ATAPI block devices.

USB

The Linux kernel configuration help for the USB support option offers this definition of the new bus:

The Universal Serial Bus (USB) is a specification for a serial bus subsystem which offers higher speeds and more features than the traditional PC serial port. The bus supplies power to peripherals and allows for hot swapping. Up to 127 USB peripherals can be connected to a single USB port in a tree structure. The USB port is the root of the tree, the peripherals are the leaves and the inner nodes are special USB devices called hubs.

Few audio devices have yet appeared for the USB interface, but at least one USB audio device (the Swissonic Studio D) is reported to work with a recent Linux kernel running on a Toshiba Satellite 2105CDS laptop. The Linux USB Project lists a variety of USB audio devices running under Linux, including digital speakers, a minidisc recorder (the Sony MZ-R70PC), and a 20-bit digital audio output device (the StereoLink 1200). USB audio is not included in the regular kernel sound configuration: you must configure the kernel for both general USB support and USB audio.

Miscellany: PCMCIA Cards And Serial Port MIDI

Yes, the Personal Computer Memory Card International Association (PCMCIA) has a bus. PCMCIA card slots are primarily found on laptop and notebook computers, but soundcard support is sparse under Linux. As of March 9 2001 David Hinds listed no soundcards in his list of "officially" supported PCMCIA cards. Werner Heuser's list of "unofficially" supported cards includes only five soundcards, and only one is verified as working (under the kernel modules, I assume). However, one exceptional PCMCIA audio card is available with an independently maintained Linux driver: the Communication Automation Corporation's Bullet3 is a rather remarkable card that includes a Texas Instrument TMS320C32 DSP and a Crystal Semiconductor CS4231A multimedia codec. A free and unsupported Linux driver is available from CAC's ftp site.

The standard RS232 serial port is found on most desktop computers, including most laptops. It is not generally regarded as an option for audio interfacing, but it has found some application as an alternative external MIDI port. The KEY MIDIator MS-124W MIDI interface is known to run with Linux: drivers are available from George Hansper's MIDI Axis, John Stone's MIDI on UNIX page, and Dave Topper's MIDIator hack page. Other Considerations

The following table compares the major sound driver sources for cost, ease of installation and configuration, technical support, and availability of source code:

Cost:

Ease (0-5):

Support:

Sources available:

kernel:

free

4

no

yes

ALSA:

free

4.5

mail list

yes

OSS/Linux:

commercial

5

yes

no

Armed with the information you've gathered here you should be able to make a wise decision in your choice of sound card drivers. The next section deals with the more technical aspects of a Linux soundcard driver and some examples of applications programming code for the device driver.

Inside the Driver

by Dave Phillips 05/17/2001

The Linux kernel sees device drivers as either block or character drivers. A block device hosts a filesystem; thus, the drivers for your IDE disks and your tape drives are all block devices. Character devices are accessed like files, and the character device driver implements the system's I/O calls (open/close, read/write) on the requested device. Drivers are compiled into the kernel or as modules to be dynamically loaded into the kernel space. Once a module occupies kernel space its services are available exactly as any other available system function. Applications can then access those services by reading and writing to the special files found in the /dev directory (e.g. /dev/dsp or /dev/audio).

Device drivers may be very simple or very complex. Writing a Linux soundcard device driver is a relatively complex task, hence the need for complete technical documentation and specifications from the card manufacturer. Happily some manufacturers have taken an open attitude about supplying that information to driver developers, and you can view the source code for the resulting kernel sound modules in /usr/src/linux/drivers/sound. Recommended modules for study include sound_core.c (the top level handler for the Linux sound system) and opl3sa.c (the driver for the Yamaha YMF701B, also known as the OPL3-SA chipset). Source Code

The source code for the OPL3-SA offers an example of a simple kernel sound driver. The basic routines found in opl3sa.c include detection/initialization, data read/write operations, and an exit/cleanup function. The following abstract demonstrates the code's adherence to the typical structure of a Linux character device driver:

#include /* necessary headers */ 
#include #undef SB_OK #include "sound_config.h" 
#include "ad1848.h" /* header for the AD1848 support chipset */ 
#include "mpu401.h" /* header for the MIDI interface */ 
/* * Begin SoundBlaster mode setup routines */ 
#ifdef SB_OK /* SoundBlaster mode defined ? */ 
#include "sb.h" /* header for SoundBlaster mode */ static int sb_initialized = 0; 
#endif static int kilroy_was_here = 0; /* some init values */ static int mpu_initialized = 0; 
static int *opl3sa_osp = NULL; static unsigned char opl3sa_read(int addr) {} 
/* set up read operation */ 
static void opl3sa_write(int addr, int data) {} /* set up write operation */ static int __init opl3sa_detect(void) {} /* detect OPL3-SA chipset */ 
/* * Probe and attach routines for the Windows Sound System mode of the OPL3-SA */ 
static int __init probe_opl3sa_wss(struct address_info *hw_config) {} 
static void __init attach_opl3sa_wss(struct address_info *hw_config) {} 
static int __init probe_opl3sa_mpu(struct address_info *hw_config) {} 
static void __exit unload_opl3sa_wss(struct address_info *hw_config) {} 
static inline void __exit unload_opl3sa_mpu(struct address_info *hw_config) {} /* * End WSS routines */ 
#ifdef SB_OK static inline void __exit unload_opl3sa_sb(struct address_info *hw_config) {} 

#endif /* * End SoundBlaster routines */ 
static int found_mpu; /* found a MIDI interface ? */ 
static struct address_info cfg; 
static struct address_info cfg_mpu; static int __initdata io = -1; 
/* initialize audio I/O port, IRQ, and DMA channels */ 
static int __initdata irq = -1; 
static int __initdata dma = -1; static int __initdata dma2 = -1; 
static int __initdata mpu_io = -1; /* initialize MIDI base address and IRQ */ 
static int __initdata mpu_irq = -1; MODULE_PARM(io,"i"); /* set parameter values */ 
MODULE_PARM(irq,"i"); 
MODULE_PARM(dma,"i");
MODULE_PARM(dma2,"i"); 
MODULE_PARM(mpu_io,"i"); 
MODULE_PARM(mpu_irq,"i"); 
static int __init init_opl3sa(void) {} /* initialize OPL3-SA */ 
static void __exit cleanup_opl3sa(void) {} /* exit and cleanup */ 
module_init(init_opl3sa); /* make it start */ 
module_exit(cleanup_opl3sa); /* make it stop */

True to form, we see the initialization, read/write, and detection routines for the chipset, load/unload routines for the WSS (Windows Sound System) and MPU (external MIDI interface) functions of the chipset, and the mandatory exit/cleanup routine.

Interested readers should consult the complete OPL3-SA driver source code for a more detailed understanding. See also the Resources listings at the end of this article for guides to more information on writing Linux device drivers. In particular, Alessandro Rubini and Jonathan Corbet's book (Linux Device Drivers) is highly recommended to anyone thinking about writing a Linux driver. Programming the Device: The OSS/Free and OSS/Linux APIs

As mentioned earlier, Linux applications do not normally access hardware directly; thus, applications developers do not usually write code to directly access and control a device such as a soundcard. Instead, an application programming interface (API) provides the developer with a hardware-independent set of I/O controls over the device's services.

The OSS/Free API (at /usr/src/linux/include/linux/soundcard.h) is the default programming interface for the kernel sound modules. The OSS/Linux API is an enhanced and expanded version of the OSS/Free programming interface; it is normally found at /usr/lib/oss/soundcard.h (the OSS/Linux default installation path).

The following code fragment illustrates how to control a soundcard by programming with the OSS/Free API:

/* * * shameless rip-off of example code by Jeff Tranter * from his Linux Multimedia Guide * */ 
#include 
#include 
#include 
#include 
#include 
#include 
int main() { int fd; /* device file descriptor */ 
int arg; int status; /*** open the device file (/dev/dsp) for read/write operations ***/ 
fd = open("/dev/dsp", O_RDWR); 
if (fd < 0) { perror("error opening /dev/dsp"); 
exit(1); } /*** set the sample size (8 or 16 bits) ***/ 
arg = 16; status = ioctl(fd, SOUND_PCM_WRITE_BITS, &arg); 
if (status == -1) { perror("error from SOUND_PCM_WRITE_BITS ioctl"); 
exit(1); } /*** set the number of channels ***/
arg = 2; 
status = ioctl(fd, SOUND_PCM_WRITE_CHANNELS, &arg); 
if (status == -1) { perror("error from SOUND_PCM_WRITE_CHANNELS ioctl"); 
exit(1); } /*** set the PCM sampling rate for the device ***/ 
arg = 44100; status = ioctl(fd, SOUND_PCM_WRITE_RATE, &arg); 
if (status == -1) { perror("error from SOUND_PCM_WRITE_RATE ioctl"); 
exit(1); } /*** The device is now open and ready to read or write data. ***/ /*** close /dev/dsp ***/ 
status = close(fd); 
if (status == -1) { perror("error closing /dev/dsp"); exit(1); } return(0); }

Note that the device interface code is hardware-independent. It does not need to know what particular soundcard you have: the API provides a generalized control interface that lets the application developer ignore the hardware specifics and write only to the device file (/dev/dsp in this example). Manipulating the bits in the hardware registers of the card is left to the driver for that card. For instance, in the fragment above, we see no indication that my soundcard is a SoundBlaster; however, my kernel sound driver is indeed the SoundBlaster module, and when an audio service is requested that module does its duty, translating the request into my SoundBlaster's unique command set.

The Linux Soundcard Driver

Introduction

Finding and Installing Drivers

The Future of Linux Audio Driver Support

The OSS/Linux applications interface is an enhanced and expanded version of OSS/Free. You can obtain the OSS/Linux API in PDF format from 4Front's site, along with some examples of coding for PCM audio, the soundcard mixer, and MIDI. The API covers a greater range of cards, and an accordingly broader range of functions, but the basic programming is similar to OSS/Free. Programming the Device: The ALSA API

The Advanced Linux Sound Architecture (ALSA) goes beyond the capabilities of the OSS/Free API and is generally regarided as the likely successor to OSS/Free as the kernel sound API. The ALSA driver can be compiled with an OSS/Free emulation mode completely compatible with the existing kernel sound API; however, given the truly advanced nature of the ALSA driver, I urge developers to write their new audio applications using ALSA in its native mode (i.e., leaving behind OSS/Free legacy code). The next code fragment shows how to do the same thing as the OSS/Free fragment, but in native ALSA mode.

// // alsa.c // ALSA API demonstration code // courtesy Andy Lo A Foe // 20 April 2001 // 
#include 
#include 
#include 
#include snd_pcm_t *sound_handle; snd_output_t *errlog; 
snd_pcm_hw_params_t *hwparams; 
int main(void) { int err; // Connect error reporting to stderr snd_output_stdio_attach(&errlog, stderr, 0); 
if (snd_pcm_open(&sound_handle, "hw:0,0", SND_PCM_STREAM_PLAYBACK, 0) < 0) { fprintf(stderr, "Error opening hw:0,0n");
snd_output_close(errlog); return 1; } 
// Set up the hardware device for 16-bit, 44KHZ, stereo // First initialize the hwparams struct using the sound_handle 
// we got for our sound hardware snd_pcm_hw_params_alloca(&hwparams); err = snd_pcm_hw_params_any(sound_handle, hwparams); 
if (err < 0) goto _alsa_error; 
// Now request the desired parameters one by one 
// Access method, interleaved or non-interleaved err = snd_pcm_hw_params_set_access(sound_handle, hwparams, SND_PCM_ACCESS_RW_INTERLEAVED); 
if (err < 0) goto _alsa_error; 
// The sample format, signed 16-bit little endian err = snd_pcm_hw_params_set_format(sound_handle, hwparams, SND_PCM_FORMAT_S16_LE); 
if (err < 0) goto _alsa_error; 
// The sample rate err = snd_pcm_hw_params_set_rate(sound_handle, hwparams, 44100, 0); 
if (err < 0) goto _alsa_error; 
// Number of channels we want, stereo = 2 err = snd_pcm_hw_params_set_channels(sound_handle, hwparams, 2); 
if (err < 0) goto _alsa_error; 
// The period size. For all practical purposes this is synonymous
 // to OSS/Free's fragment size. 
// Note that this in frames (frame = nr_channels * sample_width) 
// So a value of 1024 means 4096 bytes (1024 x 2 x 16-bits) err = snd_pcm_hw_params_set_period_size(sound_handle, hwparams, 1024, 0); 
if (err < 0) goto _alsa_error;
 // The number of periods we want to allocate, 4 is reasonable err = snd_pcm_hw_params_set_periods(sound_handle, hwparams, 4, 0); 
if (err 0) goto _alsa_error; 
// Finally setup our hardware with the selected values err = snd_pcm_hw_params(sound_handle, hwparams);
if (err < 0) { fprintf(stderr, "Unable to set hardware parameter:n"); snd_pcm_hw_params_dump(hwparams, errlog); return 2; } fprintf(stdout, "Success!n");
// At this point you can start sending PCM data to the device snd_pcm_close(sound_handle); 
snd_output_close(errlog); return 0; _alsa_error: fprintf(stderr, "Invalid hardware parameter for device:n");
snd_pcm_hw_params_dump(hwparams, errlog);
snd_pcm_close(sound_handle); snd_output_close(errlog); return 1; }

As you can see, the ALSA API permits more robust control over the device, yet retains the hardware independence necessary for a generalized programming interface. ALSA offers many amenities to audio developers, particularly for professional applications (such as multitrack, hard disk recorders) that demand higher performance from the entire system. Developers do not write directly against kernel ioctls(), and higher level support is available for PCM plugins and transparent network audio. Readers interested in the details of the ALSA API should consult asoundlib.h in the alsa-lib-x.x.x/include directory.

Andy wrote this code for ALSA 0.9.0beta, but it is likely to remain valid for the 1.0 release. The stabilization of the API will be a long-awaited achievement, one that promises a great future for the development of serious and professional Linux audio applications. There is widespread hope that the ALSA programming interface will enter the kernel sources, eventually replacing OSS/Free and providing the kernel with a more modern and more flexible sound system.

The Future of Linux Audio Driver Support

by Dave Phillips 05/17/2001

If the present trends continue the future of Linux sound driver support looks very good. Manufacturers are beginning to notice Linux, for many reasons: popular soundcard manufacturers see a market in the expanding appeal of Linux on the desktop, while the makers of professional digital audio boards are attracted by the system's robust performance and by the very low latencies possible from a simple patch to the kernel (see my article Achieving Low-Latency Response Times Under Linux for more information regarding the low-latency patches).

The continuing production of higher-quality Linux games is certainly a driving force behind greater mass-market acceptance. Excellent commercially available games such as those produced by Loki Software will broaden the Linux user base, and those users will want more and better support for more (and better) soundcards.

Creative Labs has already demonstrated hardware-accelerated OpenAL, a cross-platform API for 3D audio, and the company has already established a method for working in-hand with the Linux development community. Other soundcard manufacturers will likely recognize and follow Creative's initiative as a logical way into the Linux market.

Curiously, acceptance of Linux by the major manufacturers of high-end audio boards has been hampered by the "chicken and egg" scenario: manufacturers have been unwilling to supply Linux drivers (or their technical specifications and documentation) until they saw more professional-grade audio software for the system, but that software could not be written until the higher-quality hardware became available. That situation is changed now by the presence of Linux support for the RME Hammerfall and the development of software such as Ardour and jMax.

The eventual adoption of the ALSA API into the Linux kernel will signal another great advance in the area of Linux sound support. Current ALSA status is very near a 1.0 release, and the presence of an advanced sound API included with the kernel sources will certainly attract more applications developers.

The impact of the USB interface cannot be assessed at this time. It is too new, and there are too few Linux-friendly USB audio devices to allow any predictions. However, the audio card industry is most definitely gearing for USB, and we will surely see future development in the Linux USB audio arena.

As you have seen in this article, the Linux sound driver has gained solid ground since the first appearance of the SoundBlaster driver in 1992. Expect to see more cards supported, better installation procedures, and more powerful applications software. Given these trends, the future of the Linux audio driver is looking great. Or perhaps I should say it's sounding better all the time.

Acknowledgements

I would like to thank Andy Lo A Foe for his example code and his advice on the technical aspects of this article. Remaining errors are of course my own. I would also like to thank Hannu Savolainen, Thomas Sailer, Alan Cox, Paul Davis, and Jaroslav Kysela for their tremendous work on the Linux sound system. Without their contributions Linux users would have a mighty but mute operating system.

Resources

Online

4Front Technologies - Home for the OSS/Linux drivers ALSA - home site for the Advanced Linux Sound Architecture project The Linux Sound System - Alan Cox's page dedicated to the OSS/Free kernel sound drivers Writing A Linux Device Driver - good brief tutorial from Aditya Kulkami Write a Linux Hardware Device Driver - An excellent tutorial from Andrew O'Shaughnessy

In print

Matia, Fernando. "Writing a Linux Driver." Linux Journal, April 1998, 44-50 Rubini, Alessandro. "Driving One's Own Audio Device." Linux Journal, September 1998, 70-73 Rubini, A. Linux Device Drivers, Sebastopol, CA: O'Reilly & Associates, Inc., 1998 Rubini, A. "Miscellaneous Character Devices." Linux Journal, July 1998, 50-52 Tranter, Jeff. Linux Multimedia Guide, Sebastopol, CA: O'Reilly & Associates, Inc., 199