A User's Guide to ALSA
Since the public release of the 2.6 Linux stable kernel series, the Advanced Linux Sound Architecture (ALSA) has become the default kernel sound system. This change brings significant improvements to Linux audio and MIDI capabilities, including support for professional audio hardware, 3-D surround sound, advanced MIDI functions and software mixing or audio stream multiplexing. When combined with a kernel patched for low latency, ALSA provides resources for sound and MIDI that compare well with competing platforms and in some respects are superior to them. This is a bold claim, so let's look at ALSA to see what makes it tick.
The ALSA Project began when a young programmer named Jaroslav Kysela became frustrated with the kernel sound system's lack of full support for his Gravis Ultrasound audio/MIDI card. The Gravis card created its sounds by using sampled sounds stored in the card's memory in a file format known as PAT (patch). Banks of PAT sounds could be edited and stored by the user, as long as the user was running Microsoft Windows or Apple Mac OS. Linux, sad to say, did not provide such comprehensive resources, leaving Jaroslav with a sound card that was not fully operational.
At that time, the Linux kernel sound system was the OSS/Free system, a solid and serviceable audio/MIDI subsystem that had been with the kernel sources since the early days of Linux, thanks primarily to the pioneering work of Hannu Savolainen. Alas, OSS/Free had not kept pace with the rapidly evolving world of desktop audio production, and many sound cards either were unsupported or supported only partially, as was the case with the Gravis boards. To be fair, the OSS/Free maintainers were few; there was less organization in the general Linux audio world; and manufacturers then were, as some still are now, too secretive about their driver specifications.
It might have been possible to incorporate greater support for the Gravis cards into OSS/Free, but as Jaroslav Kysela researched the OSS/Free applications programming interface (API), he realized there was a need for a new API that could support more broadly the developments taking place with modern sound cards and digital audio interfaces. Professional and consumer-level expectations had risen, demanding support for features such as high sample rates and bit depths for professional recording, 5.1 and other 3-D/surround sound audio output arrays; multichannel digital audio I/O; and multiple MIDI I/O ports. There simply were too many advances that required fundamental changes in OSS/Free, so Jaroslav did what any truly hard-core Linux coder does: he designed a new audio/MIDI API for Linux, calling it the Advanced Linux Sound Architecture.
Designing and implementing an API that would encompass the requirements of contemporary audio is a non-trivial task, and ALSA needed many years, many programmers and many releases to attain its current status as the kernel sound system. In its earlier stages, normal users had to install the system by hand, normally as a replacement for the OSS/Free system, in order to acquire support for a card or the extended features of a card. This process included uninstalling OSS/Free and recompiling the kernel for ALSA support, at that time a decidedly non-trivial task. Nevertheless, the ranks of dedicated ALSA users grew, development flourished and eventually ALSA was incorporated into the Linux 2.5 kernel development track. Finally, with the public release of the 2.6 kernel series, ALSA became the default kernel sound system.
The ALSA home page gives us the following information:
The Advanced Linux Sound Architecture provides audio and MIDI functionality to the Linux operating system. ALSA has the following significant features:
Efficient support for all types of audio interfaces, from consumer sound cards to professional multichannel audio interfaces.
Fully modularized sound drivers.
SMP and thread-safe design.
User-space library (alsa-lib) to simplify application programming and provide higher level functionality.
Support for the older OSS API, providing binary compatibility for most OSS programs.
ALSA is released under the GPL (GNU General Public license) and the LGPL (GNU Lesser General Public License).
Let's look at each one of these features, restating them in language more comprehensible to a normal user.
Efficient support means that you can manage the basic and advanced features of supported sound cards easily, using ALSA tools such as a sound card configuration utility and mixer programs. Such tools are integral components of the complete ALSA installation.
Modularized sound drivers means that ALSA sound card drivers are easy to install and update. They also provide the means by which the user can control a card's available options in more detail. Later in this article, we show how you can work with a driver module to access and control features of an ALSA-supported sound card.
ALSA supports multiprocessor, or SMP, machines. Thread-safe is a programming term that indicates the services provided by the software can run concurrently in different threads without bothering each other. In a modern audio/MIDI application, thread safety is a Very Good Thing.
ALSA's user-space library provides programmers, and hence their programs, with easy access to ALSA's services, and its significance to the normal user may seem a rather slight matter. However, the ALSA library provides the interface through which applications can reach those functions, helping form a more homogeneous environment at the user level. Your programs can run more harmoniously with one another, with enhanced possibilities for connection and communication between applications.
ALSA evolved during the first phase of Linux sound support when most applications were using the OSS/Free API, so an OSS/Free compatibility layer was an immediate necessity for normal users. A large number of Linux sound applications still need OSS/Free compatibility, so ALSA provides seamless support for the older API. However, programmers should note that the older API now officially is deprecated.
Similis sum folio de quo ludunt venti.
|Preparing Data for Machine Learning||Apr 25, 2017|
|openHAB||Apr 24, 2017|
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
|Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi||Apr 20, 2017|
|CodeLathe's Tonido Personal Cloud||Apr 19, 2017|
|Wrapping Up the Mars Lander||Apr 18, 2017|
- Preparing Data for Machine Learning
- The Weather Outside Is Frightful (Or Is It?)
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
- From vs. to + for Microsoft and Linux
- Server Technology's HDOT Alt-Phase Switched POPS PDU
- Bash Shell Script: Building a Better March Madness Bracket