Linux's sound system

From the Linux console to evoke your attention to the simple "ding" sound, to the DVD surround sound, today's audio has become an important part of desktop computing. There are many computer users who do not need sound, but sound can add color to many computer tasks. As such, audio hardware has become a general-purpose part of almost all motherboards and operating systems, including most Linux distributions.

Unfortunately, configuring Linux sounds is a daunting task. In Linux, there are 3 sets of audio drivers, using two different APIs. On top of these drives, there are several support libraries that are designed to make life easier for programmers, but increase the complexity of configuration for end users. In fact, making the system sound is a frustrating experience for a regular user. If a distribution is not properly configured, the end user will be looking for, installing, and debugging a variety of ambiguous, imperfect document setting options.

As a survey of Linux sound systems, let's start with a general understanding of the sound architecture. It is becoming increasingly important to understand how multiple audio streams are mixed together in a simultaneous voice. On the basis of these topics, it is necessary to know the specific drivers. Sound device files and their permissions are often the source of the problem, so we'll talk about that too. In addition, a library file that supports sound can be either a blessing or a curse, so it helps to understand them. At the end of the article, when you have the basics in front of you, you can test and use sound tools and set options for common audible programs.

Ideally, the audio application should be straightforward: send a command or click a button to hear the expected sound. Behind this scenario, Linux uses several layers of tools to make sounds, as shown in Figure 1.

The exact transmission of sound data between an application and sound card depends on the program and the overall configuration of the system, which can be very different. For this reason, the problem of tracking sounds is very difficult. Is the problem with hardware corruption, driver programming errors, incorrect configuration of library files, application errors, or the interaction between these issues?

As shown in Figure 1, sound libraries and applications can deal directly with sound drivers or rely on other libraries. Some applications and libraries offer a variety of options: they can be used either directly from the driver or through other libraries. Although Figure 1 is not quite complete (and there are dozens of small voice support libraries), many of the most commonly used tools and libraries are already covered, including:

Sound hardware-although shown as only one item in Figure 1, there are actually many different kinds of sound hardware. If you don't have a Linux driver that supports your hardware, you might need to buy a new hardware.

The Open-source version of OSS is the standard Linux audio driver in the oss-2.4.x version of the kernel series. The 4Front Technologies (Http://www.opensound.com) Company also offers a commercial edition. For software, standard kernel OSS drivers are no different from the commercial version of OSS drivers. Most Linux libraries and voice tools support OSS. Although the 2.6.x version of the kernel also contains OSS, they have been officially replaced by ALSA.

ALSA-Advanced Linux Sound Architecture (alsa,http://www.alsa-project.org) is an alternative to OSS. ALSA is both compatible with OSS and provides a new approach to audio interface. ALSA, as a standard for the 2.6.x kernel, can also be compiled into modules used in the previous kernel.

Esound-esound is a library and background service designed to provide a unified interface for Linux audio systems, whether using OSS or ALSA. Esound also provides additional features that are not provided by the underlying driver, such as support for multiple audio streaming simultaneously (this library is sometimes called ESD).

Polypaudio-This library is intended to replace esound uninvited guests.

Arts-arts (http://www.arts-project.org) a sound library associated with KDE. It can be used as output by Esound, Alsa or OSS. You use arts with the background service associated with it to generate a sound that is transparent to the network transmission, which is convenient for the use of network thin terminals.

SDL-SDL (http://www.libsdl.org) is a common Cross-platform multimedia library for game developers, often installed in Linux systems with a package named LIBSDL, which can rely on a variety of other libraries or direct and voice-driven interactions.

Sound applications-ultimately your interest is in using sound applications, such as XMMS (http://www.xmms.org). These programs may be used directly to one or more audio drivers, may depend on a library, or provide you with several options.

Handling multiple audio streams

One annoying aspect of Linux sound systems is the processing of multiple audio streams. Traditionally, Linux sound systems are single-threaded: If a program is audible, no other program will be audible. In some cases, this can cause problems.

For example, suppose you set up your email software to make it sound when a new message arrives. If you are listening to a ogg file and there is a message coming, the mail program will not be able to send a new message to the beep. As more and more simple programs have the ability to emit sound, this limitation becomes a more and more serious problem.

There are two ways to solve this problem: adding multithreaded support for audio drivers and adding multiple audio support for audio libraries. You can think of the best way to add multithreaded support for audio drivers, because programs that use audio directly are not required to be modified. If all your programs use the same library, it's quicker to use a library file to handle the problem, but the benefit is very limited as long as there is a program that uses audio directly.

Today, many ALSA drivers support multiple audio streams. However, this support depends to some extent on the audio hardware. At the same time, ALSA OSS simulations do not support multiple audio streams--programs that use OSS do not enjoy this benefit unless they want to compete with other programs that use ALSA. OSS also uses a number of multi-threaded support (often referred to as multithreaded OSS). Esound, arts, and some other libraries also support multithreaded voice.

In practical terms, you should use as many multi-threaded options as possible. If a program lets you choose to use a multithreaded library or use a driver that does not support multithreading, you should choose to use the library if possible. If you can choose between Alsa and OSS, and your ALSA driver supports multiple threads, use ALSA driver. You may not be able to set each program to use multithreaded solutions, but you are likely to be able to set most frequently used audio programs to multithreading.