Linux audio API Guide

Due to historical reasons, there are multiple API systems available for sound programming in Linux. However, without proper guidance, it is difficult to find a system that suits your needs. Here is a guide written by Lennart Poettering <mzoybt (at) 0 pointer (dot) net> (See Homepage of Lennart) to bring you out of this forest.

　　The simplest guide is to ask yourself: "What do I want (using the Linux Sound API) to do? ". The answer is as follows:I want to write a media player-like software!

Then use GStreamer. Unless you only want to program based on KDE, you can choose to use Phonon.

I want to add the event sound to my application!

Use libcanberra and install the Sound file according to the XDG Sound Theming/Naming specifications. If you only use KDE, you can use knots, but the key points are different.

I want to develop professional audio programming, including hard disk recording, music synthesis, and MIDI interface!

Use JACK or the complete ALSA interface.

I want to play and capture basic PCM audio!

Use the safe ALSA subset.

I want to add a sound to the game!

For large full-screen games, use the SDL sound API. For a simple game, only use the basic user interface such as Gtk + and use libcanberra.

I want to write a mixed speaker/volume control software!

This depends on the level at which you want to provide direct support: If you want to support enhanced desktop software multiplexing, use the PulseAudio volume control API. If you want to support the hardware mixer, use the ALSA mixer API.

I want to write a software that supports plumbing layer!

Use the complete ALSA system.

I want to write an embedded audio software!

From the technical perspective, the safe ALSA subset is a good choice, but other APIs can be used based on your actual situation.

　　Do you want to know more about the differences between these Apis?

GStreamer is a de facto standard for a Linux Desktop Media Stream system. It supports audio/video stream encoding and decoding. This API can be used to implement a wide range of applications, from simple audio file playback to network streaming media configuration. GStreamer supports multiple codecs and audio backend. GStreamer is obviously not suitable for basic PCM audio playback or low-latency/real-time applications. GStreamer is portable and can be used only on Linux. It supports the following audio backends: ALSA, OSS, and PulseAudio. [API Reference]

Libcanberra is an abstract event sound API. It is the implementation of XDG sound themes and naming rules. Although libcanberra is part of GNOME, it can be used in other table environments. In addition to providing a simple interface for playing audio files, it also provides a buffer mechanism (suitable for network-based thin clients) and allows the transmission of a variety of metadata to the underlying sound system for control, so as to enhance the user experience (such as positioning event sound) and improve ease of operation. Libcanberra supports multiple backend servers and is portable. Currently, the supported backend services include ALSA, OSS, PulseAudio, and GStreamer. [API Reference]

JACK is a sound system used to connect professional audio applications and hardware input and output. The system focuses on the connection between low latency and applications. Therefore, the system is not suitable for common desktop applications or embedded applications. This system is not very useful if you want to simply play PCM audio. JACK supports multiple backend services. The best supported is ALSA. JACK is also portable. [API Reference]

ALSA is a Linux API dedicated to PCM audio playback and recording. ALSA focuses on hardware devices, but also supports other backend devices. ALSA represents both the audio driver of the Linux kernel and the user space function library built around the driver. The ALSA function library is comprehensive and portable. The complete alsa api can be very complex and huge, but it can support almost all audio devices. However, some functions of the alsa api depend on the Linux core and the hardware supported by the corresponding Linux driver. For example, a software-based audio server or an audio driver in the user space (Bluetooth and FireWire audio support ).

[API Reference]

Only one subset of all ALSA APIs can work on all the backend supported by ALSA. Therefore, if you write software that uses ALSA and the software is portable, backward compatible, and compatible with various audio service providers, Bluetooth audio, and FireWire audio, you should only use this secure API subset called Safe ALSA. This subset is a basic and portable Implementation of PCM audio playback and recording functions. It also supports OSS, PulseAudio, and JACK in addition to the devices supported by the ALSA core itself.

Phonon is an abstract implementation of a high-level media stream system, for example, GStreamer. However, Phonon is more advanced than GStreamer. KNotify is a system used for "prompting". It not only supports event sound. However, XDG Sound Theming/Naming Specifications are not currently supported. It does not support buffering or passing Event metadata to lower-level audio systems. KNotify supports multiple audio backends for playback through Phonon. These two APIs are only for the KDE/Qt System, so they cannot be used in applications outside the system. [Phonon API Reference] [knotted API Reference]

SDL is a cross-platform and portable API used for full-screen game development. SDL includes many things, one of which is a portable audio interface. SDL also supports OSS, PulseAudio, and ALSA as the backend.

[API Reference]

　　

 

From: http://www.itpcs.cn/html-77060-1.html