Linux Voice System

Linux voice system-general Linux technology-Linux programming and kernel information. The following is a detailed description. Audio has become an important part of desktop computing today, from the simple Ding sound that calls your attention on the Linux console to the loop sound of the DVD. There are indeed many computer users who don't need sound, but sound can add color to many computer tasks. As such, the audio hardware has become a common component of almost all the main boards and operating systems, including most Linux releases.

Unfortunately, configuring Linux sounds is a headache. In Linux, there are three audio drivers that use two different APIs. There are also several support libraries based on these drivers, aiming to make programmers better off, but adding configuration complexity to end users. In fact, for a common user, making the system sound will become a depressing experience. If the sound is not correctly configured for a release, the end user will be looking for, installing, and debugging various ambiguous setting options without comprehensive documentation.

As a survey of the Linux sound system, let's start with our overall understanding of the sound architecture. It is becoming increasingly important to understand how multiple audio streams are mixed together for Synchronous voice. On the basis of these topics, it is necessary to understand specific drivers. Sound device files and their permissions are often the root cause of problems, so we will also talk about this topic. In addition, the library files supporting sound can be both blessing and curse, so it is helpful to understand them. At the end of the article, you can test and use sound tools and set options for common voice programs.

Ideally, the audio application should be straightforward: send a command or click a button to hear the expected sound. Behind this situation, Linux uses several levels of tools to speak out, as shown in figure 1.

The exact transfer path of sound data between an application and the sound card depends on the program and the overall configuration of the system. For this reason, it is very difficult to track the sound. The problem is hardware damage, programming errors of the driver, misconfiguration of library files, application errors, or the interaction between these problems?

Sound and audio libraries and applications can both directly deal with sound drivers or rely on other libraries. Some applications and libraries provide multiple options: They can either directly use the driver or use other libraries. Although not yet complete (there are dozens of small sound support libraries), many of the most commonly used tools and libraries are involved, including:

Sound Hardware-although only one item is displayed in the middle, there are actually many different types of sound hardware. If you do not have a Linux driver that supports your hardware, you may need to buy a new hardware.

In the kernel series of OSS-2.4.x, the open-source version of OSS is a standard Linux audio driver. 4 Front Technologies also provides the commercial version. For software, the standard kernel OSS driver is no different from the commercial OSS driver. Most Linux libraries and sound sending tools support OSS. Although 2.6.x kernel also includes OSS, they have been officially replaced by ALSA.

ALSA-advanced Linux sound architecture is an alternative to OSS. ALSA is compatible with OSS and provides new audio interface methods. As the 2.6.x kernel standard, ALSA can also be compiled into modules used in previous kernels.

ESOUND-EsounD is a library and background service, designed to provide a unified interface for the Linux audio system, whether using OSS or ALSA. EsounD also provides some additional features not provided by the underlying driver, such as supporting simultaneous sound of multiple audio streams (this library is also called esd ).

POLYPAUDIO-this library is intended to replace the unexpected customers of EsounD.

The audio library associated with KDE. It can be output using EsounD, ALSA, or OSS. You can use aRts to produce transparent voice for network transmission through the background services associated with it, which is very convenient for using thin network terminals.

SDL-SDL is a cross-platform multi-media library commonly used by game developers. It is often installed in Linux using a package named libsdl, it can rely on a variety of other libraries or directly deal with sound drivers.

Sound application-your interest is in using sound applications, such as XMMS. These programs may directly use one or more audio drivers, depending on a library, or provide you with several options.
Process multiple audio streams

An annoying aspect of the Linux sound system is processing multiple audio streams. Traditionally, the Linux sound system is single-threaded: if a program is audible, other programs cannot be audible. In some cases, this may cause problems.

For example, assume that you have set the email software to make a sound when a new email arrives. If you are listening to an OGG file and receive an email, the email program will not be able to send a prompt when a new email arrives. As more and more simple programs have voice functions, such restrictions become a more and more serious problem.

There are two solutions to this problem: Add multithreading support for the audio driver and add multi-audio support for the audio library. It can be considered that it is the best way to add multi-thread support for the audio driver, because the program directly using the audio driver does not need to be modified. If all your programs use the same library, it is faster to use the library file to handle this problem, but as long as one program uses the audio driver directly, this benefit is very limited.

Today, many ALSA drivers support multiple audio streams. However, this support depends to some extent on the audio hardware. At the same time, the OSS simulation of ALSA does not support multi-audio streams-the OSS program does not enjoy this benefit unless it wants to compete with other programs using ALSA. OSS also supports multiple threads (often called multi-thread OSS ). EsounD, aRts, and some other libraries also support multithreading.

In practice, you should use as many threads as possible. If a program allows you to choose whether to use a multi-threaded library or directly use a driver that does not support multiple threads, you should choose to use the library in all possible cases. If you can choose between ALSA and OSS, and your ALSA driver supports multithreading, use the ALSA driver. You may not be able to set a multi-thread solution for every program, but you may be able to set most programs that frequently use sound to multithreading.

Start the driver
The driver represents the core of the Linux sound system. Therefore, it is critical to compile and install the driver. Unfortunately, this task sometimes looks like a magic. Linux audio drivers are notoriously difficult to serve. The cause of the problem at the driver level includes the wrong driver, the mutual interference between different types of drivers (ALSA and OSS), and the wrong driver (through the wrong sound device file, ).

First, you must decide whether to use the ALSA driver, the kernel OSS driver, or the commercial OSS driver. To this end, you should check your hardware compatibility on the website or using the Kernel configuration tool. If your hardware supports multiple drivers, you have to test one by one to find the best one. But be careful-if you try to directly load the two drivers to the kernel at the same time, you can only work at most one of them. To try it one by one, you need to compile two kernels or compile the driver into a module, so that you can load or uninstall it as you wish.

If your system already has a basic sound, it is best not to change the configuration unless necessary (for example, you need to re-compile the kernel for other reasons ).

Select "Device Drivers, Sound, and Sound Card Support" when selecting the driver to be compiled. Then, make a choice between ALSA or OSS and set options.

Generally, it is much easier to compile audio drivers directly into the kernel than to compile them into modules, but compiling them into modules is more flexible because you can load or uninstall them at will. When compiling the ALSA module, select the OSS compatibility option (both mixer and PCM functions are required), because many programs use the OSS device directly for programming, if you do not include the compatibility layer, they will not work. If you want to use a commercial OSS driver, you must set basic OSS support in the kernel, but do not choose to compile your audio card driver into the kernel (only compile it into a module at most ).

Once you re-compile the kernel and restart it with the new kernel, the sound may be normal or abnormal, depending on whether the options you set are accurate. If you compile key functions into modules, You need to load them. You can use common commands such as modprobe to do this. However, some drivers need to set specific parameters during loading, which is often the case for ALSA. View Details on the ALSA website. Each sound card is different. Typically, you must add several lines of alias commands to the/etc/modules. conf file.

Audio Device File
Many Linux drivers allow programs to read and write device files to use hardware. These files are stored in the/dev directory and subdirectory. This is also true for audio devices. Programs that do not use library files directly use device files, while programs that use library files indirectly use device files through library files.

Table 1 summarizes the most important audio files corresponding to OSS and ALSA. These Device Files fall into several categories based on their purposes. (Most file names end with 0 or C0D0. When you have multiple sound cards, these numbers change and are omitted in some cases .)

Table 1: Important Audio Device Files
Device Type OSS ALSA
Digital sampling/dev/dsp0/dev/snd/pcmC0D0
Sun audio compatibility/dev/audio0 N/
Mixed speaker/dev/mixer0/dev/snd/mixerC0D0
High-level sequencer/dev/music0 N/
Low-level sequencer/dev/midi0 N/
Sound status/dev/sndstat N/
Control File N/A/dev/snd/controlC0

For most functions, the most important file is the digital sampling file that processes the input and output of digital audio, and the mixed audio file that enables the tuner to control the volume. Sun audio compatibility provides interfaces compatible with Sun Workstation, corresponding to some very old programs. Sequencer files allow you to play MIDI files, but not all drivers support this feature. The status and control files provide information and control interfaces for the sound card.

Earlier versions of ALSA require you to run a script named snddevices to generate sound device files. These files should be automatically generated in later versions of ALSA, or they should be created by default in most current Linux releases.

Even so, if you cannot find the appropriate audio device file, you should look for the snddevices script and run it.

An important detail is that users who intend to use sound applications must have the read and write permissions on the device files, at least the OSS-style access permission. Most Linux distributions use one of two ways to solve this problem: or provide a group with write permissions (such as audio or sound group), you can add users; or change the ownership of the device file to the current login user. The former causes conflicts when users log on remotely and use sound applications, while the latter causes problems when multiple users log on to the system (for example, you have to log on with multiple user names ).

Install library files

Many programs depend on the sound library, so you must install these library files first. Fortunately, if you know which library files are needed, this task is quite simple, as long as you find and install a software package suitable for your release.

Some problems with library files are that you do not necessarily know the specific requirements when using a specific program. Some programs hide some options when they cannot find the required library files. In addition, when you install tar.gz or use other methods to bypass your package management system.

However, when you use RPM or Debian packages to install programs, if the software you are trying to install depends on a library file that you have not yet installed, the package management tool will send a prompt. In this case, you need to follow the clues to find the database. (Some package management tools, such as APT, will automatically help you do this)

It is worth a little detail about Gentoo. Because it adopts the "all self-compiled" method, gentoo allows you to explicitly include or exclude support for specific audio library files in your program-at least for programs that support these options during compilation. The/etc/make. profile/make. defaults file contains a list of all library files that may be used, each of which occupies one row.

If you know that you do not want to use a library, for example, SDL, you should comment out the sdl line in the above file unless absolutely necessary. You can also make some changes each time you run emerge. You can add the database name to provide support, or add a "-" before the Database Name (for example,-sdl) to ignore the support for these libraries. However, these options are only valid when these libraries are listed as "optional" (optional) library files of the software package.

For example, if the software package requires SDL to work properly, specifying the-sdl option in the emerge command does not work. You should be careful with these problems because the options of the program may appear or disappear. In some cases, they also affect the audio quality of the program. If one database works better on your hardware and programs than the other database, your choice will affect the quality of sound output.

To obtain such control, in the traditional binary Linux release, you must re-compile the software package with the source code, or simply bypass the package management system, you can use the compilation options you like to generate customized software packages.

Some libraries provide configuration tools for setting various options. For example, aRts allows you to choose ALSA, OSS, or EsounD (More details will be provided soon ). You may want to see the document of the library file to find out what options it provides.

Testing and using sound tools
After installing all the library files and drivers, you can start to test the sound. To do this, you 'd better start with the simplest tool-those that don't depend on the driver. Then, we will gradually test other tools that use different library files.

Play
The play command directly uses the OSS Driver (or ALSA's OSS compatibility layer) to play audio files. For example, input play test.wav to play test.wav. In addition to using cat to directly send a sound file to a sound device file (which will substantially distort the sound), this is the easiest way to test the functionality and operability of your sound system. If you have used ALSA but failed to compile or load OSS compatibility support, the play command will not work.

Aplay
The role of aplay in ALSA is equivalent to play, and its usage is the same. If you use ALSA, you should try both tools. If aplay can be used but play cannot be used, it usually indicates that you failed to compile or load OSS compatibility support.

Esdplay
This command is very similar to play and aplay, but it only plays files through EsounD.

These programs only contain relatively simple files, such as. wav files. They cannot properly process MP3, Ogg Vorbis, or other complex file types.

Ideally, you can use these programs as normal users. However, if your permission on the OSS device file is incorrect, you may only be able to play the sound as root. If so, check your device file permissions and try again.

These programs all have corresponding recording programs: rec, arecord, and esdrec. You should be able to use these commands to record a sound file. Depending on your mixer settings, the generated file may be completely blank, even if you have given the sound card an appropriate input.

When talking about mixer, pay attention to it, especially when using ALSA. According to the default settings, all output channels are muted when ALSA is started. Therefore, you may be able to play a sound file, but nothing can be heard (the playing program may temporarily "Frozen", but after a while when the file is played quietly, ). There are many types of mixer programs, including mixer, amixer, alsamixer, kmix, and gnome-volume-control. The first three are text interfaces and the rest are graphic interfaces. Amixer and alsamixer only use the ALSA interface. Other OSS interfaces or both are supported. The gnome Volume Adjustment Program is displayed.

You should ensure that the channels you need are muted and the volume adjustment slider is set at the appropriate level (you need to experiment to know what is "appropriate "). The "Mater" and "PCM" options are critical for sound playing. If you want to play a music CD, you may also need to set the CD option.

For recording, you usually have to mute the Mic or Line option. Many sound cards provide additional options that may be important or irrelevant. For example, if you only have two traditional speakers, the volume option of surround sound is not important. However, if you use a full set of surround sound systems, it is another matter.

When the computer is restarted, the mixer settings are reset. To solve this problem, you can use a mix that can read the volume settings from a text file. In a local STARTUP script, such as/etc/rc. d/rc. local, add a call to this program or set a call from a SysV-style STARTUP script.

For OSS, the mixer program is a good choice, but you need to find the best option from the experiment. For more information, see manpage. For ALSA, a shortcut is to use alsactl. This program can save the current mixer to a file or read it from the file. When you are satisfied with your favorite audio mixing program, enter alsactl store as root. This command stores the sound mixing settings in/etc/asound. state. After that, you can call alsactl restore in a STARTUP script to restore the settings (some released ALSA startup scripts already include this function ).

In addition to simple sound recording, recording and sound mixing programs, there are also many more complex Audio Tools. For example, xmms is a common program for playing Ogg Vorbis and MP3 files. xine is a tool for playing MPEG streaming media. Of course, there are also many games that play audio. In fact, sound has already been used in many programs that you generally don't know how to play. For example, most desktop environments, such as KDE and GNOME, can associate sound with specific events, such as starting a program or a console ringtone.

Set KDE/aRts options
Many applications and libraries provide sound-related options. These options allow you to choose how the sound is output (directly through the driver or through the Library), or provide more fine-grained options (such as timing options ). If you have installed Multiple sound cards, you may be able to choose which one you want to use. Although listing all the options of all applications is impossible, some examples can help you establish what can be done.

Let's take a look at the options for setting KDE/aRts and XMMS.

KDE allows you to adjust the output options through the control center (enter the kcontrol command or select from the menu ). These controls are actually set up the aRts-KDE sound library. These options are located in the "Sound and multimedia, sound system" section of the control center, see (some releases may have slightly different names ).

The "General" label allows you to set features such as network accessibility and automatic suspension of CPU usage (when the driver does not support multithreading, and you cannot tell aRts to use a low-level multi-threaded library, it is best to enable the last feature ). You can also click "Test Sound" and "Test MIDI" to Test the aRts settings (the latter does not work on each Sound card ).

The "Hardware" label sets lower-level options. Note the "Select the Audio Device" button. You can tell aRts which one to choose from among several low-level drivers and libraries. Typical options include auto-detect, ALSA, OSS, Threaded OSS, and EsounD. The content listed on different systems varies depending on the installed driver and KDE compilation options.

The default setting is usually auto-detect, which is acceptable. However, if there is a problem with the sound quality of the KDE application (or other programs that use aRts) or the sound characteristics of KDE interfere with other programs, you can test other options. You can also set additional options, such as sampling rate and quality. Once again, the default options are generally acceptable, but you can adjust them when there is a problem.

Set XMMS options
As a dedicated multimedia application, XMMS provides more audio options than most programs. However, these options are not completely obvious. Right-click the XMMS menu bar and select "Option, Preferences". The displayed XMMS "Preferences" dialog box is displayed.

The most important option of XMMS is the "Output Plug-in" button, which enables you to choose the Output driver. You can usually choose between ALSA, OSS, and EsounD. However, the exact options vary depending on the release and installed output plug-ins.

Once you select the output method to use, you can also click "Configure" to fine tune the model. It will bring a plug-in-specific dialog box for you to set other features. For example, you can use the ALSA plug-in to select the desired audio device, start or stop the Mmap mode, and so on.

Sometimes, these options will have a great impact on the quality of the sound you hear, so when something goes wrong, you should try different options.