Talk about audio problems under Linux (GO)

Transfer from http://www.kunli.info/2009/03/24/linux-sound-issue/

Today's Internet, compare Linux and Windows War stickers basically all become menstruation stickers. A group of radical users continue to attack each other vigorously, but few can come up with fresh dry goods, basically for both reasons I can now back. One of the most important reasons for attacking Linux is that hardware drivers are not perfect.

The problem of sound card which is to be talked about today is a kind of "driving" problem. I work in my Notebook, home notebook, work with the server two, above all installed Ubuntu, no exception encountered the problem of sound. To ubuntu.org to see, complaining about sound card problems, whether it is rookie, Middle bird or veteran. Of course not just Ubuntu,debian, redhat (including Fedora), as far as I know, I can find a similar problem. My blog also has an article on sound issues. What causes Linux to be so hard to sound?

There's a very good post on the official Ubuntu forum that talks about this. This article is actually the original Chinese expression. But this is only from the theoretical height of analysis, if you are experiencing problems, through the search engine came here, please directly read the article "Summary", this part of the reference post is basically Ubuntu audio problem Daquan.

Now let's take a bottom-up analysis of this problem from the bottom up.

First of all, the Linux community is facing the biggest and most realistic status quo, is to get too little support. From the chip level, each OEM has the ability to configure the wiring connection to meet the needs of their own production machines, such as a manufacturer can make two microphone interface on the machine, one on the front panel, one on the back panel, and the other vendor may be configured in reverse, and so on. Businessmen finish personalization, fix windows drivers, it's all right to celebrate, poor our Linux community has to deal with different configurations of different machines, and then make sure that users can figure out what the configuration of their machines.

From the level of the sound card itself. Currently, the most popular of desktops is the innovative sound card. The most frustrating thing is that the innovative Linux drivers have never been done. Innovation oneself also have no way, simply give up this piece of development, in November last year announced the public release sound Blaster X-fi and X-fi Titanium series of Linux 32/64-bit Drive source code, say good point, called the people gather wood flame high, say not to listen to point, Is that ye do not play, who love to use who development. Of course there are some support better, such as C-media some of the onboard, or the kind of high-end and professional sound card.

Are you feeling depressed? The problem with Linux is here, if you find that the x vendor released a super-awesome limited edition of 1000 sets of hardware, and then you want to start to show off the surrounding many friends, and unfortunately you use Linux ... well, You have to pray that there are at least 2-3 Linux developers in the 999 other purchases, note, not the so-called master. Then put the hardware in the home for a few months, waiting for the launch of the drive ....

Why is Linux driving so hard to develop? Some people will say, the driver is not a translation conversion parts, your sound card chip is not through the operating system provided by the underlying services and other software to deal with it, the Linux source code is there, so many of the underlying hardware driver examples are there, how can you not develop it?

Yes, the role of the driver is to tell the operating system to pass over the command and request translation and submit to the sound card chip, and the results feedback. Because of this, the driver must know the hardware details very well. It has to know, and can detect, what those vendors do to the chip's firmware or configuration circuitry, because OEMs never bother to post this information. Otherwise, even the same chip, can not be guaranteed to adapt to different cable collocation. How difficult is this? For example, even on the same chipset of the same computer, the new 7.1 surround sound card chip microphone input line, it may be and the previous old 5.1 of the configured sound card chip speaker output with the same line.

Now, you know where the problem is? As driver writers, they can let the driver adapt to all the changes that can be found, but it's like a guessing game without an end. So, if you have a special sound card chip and trapped in its Linux driver, please do not blame the writing driver, they have spring silkworm to die silk side. Today, the most famous and active Ubuntu/linux-driven writing team is counting ALSA and OSS, and what we can do about this extremely difficult task that they accept should be a tribute to them.

Speaking of the driver, speaking of audio server it. An audio server is something that is located at the top of the drive, and it is responsible for providing kernel services to applications that require audio support, as well as dispatching these services, and interface abstractions that interact with other hardware and software. In general, the audio server is used to connect the application to your sound card, or to the network, or nowhere, if you configure the wrong words.

The ALSA and OSS teams mentioned earlier not only provide drivers, but also provide services for audio servers. For Alsa, most of the services offered are run separately, such as the esd,enlightened sound Demon, which allows multiple applications to share audio services. These programs have been in development for several years, but they are all in a more chaotic way to address the flaws that have been observed. The OSS, however, is an older project, which is the only recognized audio system in the kernel version of the 2.4.x period, but was later replaced by Alsa and survived. For a comparison of the two, please refer to here, I will not go into the explanation. The OSS was later rewritten, named OSS4, and is now active.

The next pulseaudio is a relatively new, completely independent audio server, except that it leverages the ALSA driver, so its goal is to replace the ALSA audio server, including all ancillary parts, such as ESD. PulseAudio is also committed to providing ALSA features that were difficult to provide, such as webcasts, synchronizing multiple sound cards, controlling the volume of different applications, and many other fun features. There are also anecdotal notes that PulseAudio is experimenting to see if it can work on OSS4.1 basis.

Then we look at JACKD. Many people think of JACKD as an audio server, which is actually inaccurate, it's not an audio server, it's essentially an audio connection kit. It is designed around the services that are needed to deliver certain applications. What kind of application? It's the ones who serve the professionals in the music industry, and what's special about these applications is that they need to be "real-time." For example, they may be located in an operating system that supports real-time kernel/CPU priority access and low-level driver access to reduce delays or interruptions that may occur in some time-sensitive activities, such as live recording, acting, and so on. JACKD supports all applications written in the Jack API suite to be connected and operated locally or remotely by a keyboard or MIDI device. So, JACKD is very suitable for musicians. But it is because JACKD provides such a low level of control that it needs to be carefully controlled and may conflict with the same audio servers that want to dominate these resources. With this in mind, both the ALSA OSS and the PulseAudio Audio server provide specialized modules that are responsible for and JACKD interaction.

Another thing worth mentioning is phonon, a new audio server and application API specifically for KDE, compatible with PulseAudio and ALSA drivers. Please take this article for specific introduction.

Finish the audio server, and then talk about the interface. Unlike drivers, an audio server needs a common interface that users can interact with and tell their own needs. Where is this interface? In the menu inside the system/preferences/sound inside, open look. Here, you can specify that the sound of the system be sent to the audio server, or directly to the driver. The former will cause the audio server to control everything, the latter will be driven mainly by the server as a supplement. If you choose AutoDetect, how the first application determines the sound transmission path, then the application follows this path. If you choose an audio server, the server will help you manage it, and you can make some adjustments on top of it. Like ALSA can call the ESD to do voice sharing, PulseAudio will take care of this. You can also have an audio server call another, such as let PulseAudio as the default sound card for ALSA, so that all ALSA related programs will be redirected to PulseAudio, the process, the application is not known.

For ALSA, its interface includes a lot of tuning tools, the most basic is to call the Alsamixer in the terminal, of course, you can also use the GUI version of the alsamixer. In the tuning tool, you can control your sound card with a variety of sliders and switches, and of course the sliders and switches depend on the type of sound card you have. And, of course, we're more familiar with the volume controller, where you can adjust a lot of options. ALSA another commonly used interface is the ASOUNDRC file, you can edit it manually, or you can use the ASOUNDCONF-GTK to adjust the options.

For PulseAudio, it has no deep control over the driver itself, so PulseAudio is also the ALSA tuning tool to invoke. The PulseAudio can then control the master volume, the volume of the channel, the volume of the application, and so on. The PulseAudio interface gives the user a very detailed control option, in PulseAudio volume control, which is Pavucontrol, you can see all of your input and can set any one of them as the default device. You can also control the volume of any program without affecting the operation of the application, as well as the devices it uses. In the Pulse audio Preferences (paprefs), you can control network access to your audio devices, build RTP servers, and even create virtual devices that are virtually identical to actual hardware devices.

It is because of so many different audio formats, different audio servers, in order to ensure that the audio still works properly, we finally have to be brought into an era filled with audio filters, plugins, wrappers (wrapper) and other components. In order to make people understand how these things work, give the famous Amarok as an example.

When you are ready to use Amarok to play MP3, Amarok will first look at the file you specified, and then say to yourself, OK, now I need some help, let me see who can help me ... OK, Xine engine, you kid has mp3 plugin, to convert mp3 file into something I can use, that's you. Xine a look, yo, Amarok need help, how can I leave, immediately will mp3 plug-in hands. Amarok will say to Xine again, can you help me to send the data to the PulseAudio audio server? Xine Natural dare not snub, immediately find PulseAudio, said, dude, I here have Amarok sent over the stream data, can you help to play it? PulseAudio said, no problem, bring it over. So Amarok gets the message, starts processing the file, sends it to Xine,xine to convert it to PCM, and sends the PCM to Pulseaudio,pulseaudio to send the stream data to the ALSA output audio device responsible for driving. If the device is a speaker or headset, the PCM will be adjusted in the ALSA volume control so that you can hear it. So the final whole process is this.

Amarok-xine-pulseaudio-alsa Driver-sound Card-speakers

Only Xine can do this kind of back-end processing service? No, another name of the service is called GStreamer, like to use Rhythmbox friend estimates will not be unfamiliar with it. In fact, GStreamer and Xine can also provide video processing services, as long as the corresponding plug-in and filter support on the line. This approach is more appealing to program developers because they only have to write interfaces that are GStreamer or xine interactive, and other details don't care. GStreamer and Xine also provide configuration files that can be changed.

For plug-ins, program developers can create their own plugins, in fact, whether it is GStreamer or xine, or Alsa or OSS or PulseAudio or Jack, is a very common program plug-in. The audio server also contains a variety of plug-ins, such as PulseAudio has a lot of plug-ins called modules. ALSA also has a lot of plugins packaged into Libasound2 and Libasound2-plugins. Plugins are a good thing, and users should be able to have them as much as possible, so that there is better flexibility and a wider choice.

Summary :
Basically, this is the basic knowledge that the audio system works in the system. Hope to see the friends here have not been knocked out of the head. This article only gives you a basic concept, and does not involve a lot of detail. About the specific many problems are how to produce, how to solve, you can refer to some information

Talk about audio problems under Linux (GO)