On the ALSA Track

A look at the history of Linux sound architectures and some of the benefits of ALSA.

On the ALSA Web site, you read that ALSA stands for the Advanced Linux Sound Architecture. Normal users normally don't think about such things as sound architectures, so before I say more about ALSA and why it's advanced, I must present a brief description and history of the Linux sound architecture.

A sound architecture may provide a variety of audio-related functions, but it must include at least a low-level connection between the soundcard driver and kernel services and a higher-level audio software programming interface to simplify applications development. Until the 2.5.x development track, the Linux kernel utilized an audio API now known as OSS/Free. OSS here stands for Open Sound System, an audio API originally written in 1992 by Hannu Savolainen. Independent developers contributed drivers and other work to the OSS/Free system, but by the late 1990s the OSS API was showing its age. Around that time, a Czech system administrator named Jaroslav Kysela began work on what eventually became the ALSA project. Like Linux itself, ALSA began with rather modest goals: Jaroslav simply wanted more out of his Gravis UltraSound soundcard than the existing API could deliver, and he was willing and able to meet the demands of the task. Like Linus Torvalds, Jaroslav eventually found himself at the center of a group of talented developers, all dedicated to the development of a superior audio API for Linux.

ALSA's features and popularity grew to a point when users and developers began lobbying for utilizing ALSA to replace the OSS/Free system packaged with the kernel sources. Testing began with the 2.5.x development kernels, and from the 2.6.x kernels onward ALSA has been the default Linux sound architecture.

As mentioned, ALSA's developers have concerned themselves with designing a truly superior sound system for Linux. On the ALSA Web site we read this description of the project's most significant features:

  • Efficient support for all types of audio interfaces, from consumer soundcards to professional multichannel audio interfaces.

  • Fully modularized sound drivers.

  • SMP and thread-safe design.

  • User space library to simplify application programming and provide higher level functionality.

  • Support for the older OSS/Free API, providing binary compatibility for most OSS/Free programs.

  • Licensed under the GPL and the LGPL.

This article is not intended to be a guide to installing or programming ALSA, nor does it describe every feature. I merely consider the features in the list above rather generally and briefly describe how I take advantage of ALSA on my own system.

Cards & Drivers

For most normal users, perhaps the first and most important question is "Does ALSA support my soundcard ?" Linux support for audio hardware has been problematic due to the unwillingness of many manufacturers to provide either drivers or the specifications from which Linux drivers could be written. Notable exceptions have occurred, however, and by now ALSA supports many of the most popular soundcards and audio boards, including hardware from Creative Labs, RME and M-Audio. ALSA's driver support extends to serial and parallel port interfaces as well as to PCMCIA and USB hardware. ALSA even goes beyond hardware, providing a dummy driver and a most useful virtual MIDI driver. See the ALSA Soundcard Matrix for the current list of supported cards and chipsets.

Figure 1. The alsaconf Soundcard Configuration Utility

Mainstream Linux distributions try to identify and install the correct driver for your soundcard during the configuration stage of an initial installation. Usually a standalone sound configuration utility is included for tweaking beyond the original installation. ALSA provides alsaconf (see Figure 1), which is fine for simple card configurations, but it's not so good with systems having multiple cards, nor does it handle loading the virtual or dummy drivers. Fortunately, it's a simple matter to load and unload ALSA drivers (more about that in the following section).

I've used ALSA with quite a variety of soundcards. My current systems (desktop and laptop) enjoy ALSA support for an SBLive and a PCI128 on the desktop machine and a CS4232 audio chipset on my laptop. The external MIDI hardware is active on the soundcards, the EMU10k1 synthesizer is fully operational on the SBLive and both machines employ the virtual MIDI module. I also have a Core Sound PDAudio-CF PCMCIA card working nicely with the laptop and ALSA driver, giving me an excellent digital audio interface for that machine.

______________________

Similis sum folio de quo ludunt venti.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: On the ALSA Track

Anonymous's picture

I have the M-Audio Audiophile card running through ALSA with envy24. I can route stereo audio through channel 9 and 10 of the envy24 mixer in order to playthrough the spdif out, but is it possible to use ac3dec or ac3play or something similar to play ac3 files through the spdif output. Can anyone help?

Re: On the ALSA Track

Anonymous's picture

"The external MIDI hardware is active on the soundcards, the EMU10k1 synthesizer is fully operational on the SBLive and both machines employ the virtual MIDI module."

This statement seems a bit misleading as I don't believe ALSA alone can do it. I have seen others on the ALSA mailing lists talk about having the synthesizer fully functional on an EMU10k1, but have yet to see anyone describe how to actually achieve it. It does not appear to be possible strictly via ALSA, there must be some other driver or app necessary.

I would love to be able to get my SBLive fully enabled under Linux. If anyone knows how, or knows of a tutorial that describes how, please share the secret.

EMU10K1 = SBLive?

Anonymous's picture

A few years ago, the underground of home studio hobbyists somehow discovered that the EMU card chipset was build into the SBLive cards. They found that they could use the EMU drivers for the SBLive cards and get all of the functionality of the EMU cards($600 cards versus $100 SBLive cards!)

This was not long after EMU was bought by Creative.

Maybe someone has specifics, but I can tell you for sure that I RAN out and bought the SBLive card and, sure enough, it worked. This was around 97, FWIW.

Re: On the ALSA Track

Anonymous's picture

Take a look at the ALSA em10k1 wiki, maybe you can find the information you need:

http://alsa.opensrc.org/index.php?page=emu10k1

Re: On the ALSA Track

Anonymous's picture

Nowhere have we seen anything about embedded sound solutions that main board makers have engineered in. Realtek(AC97) chipset is the 5.1 channel sound system on my Abit IC7-G MAX2 main board. So where does this leave the embedded sound system users?

MontyW
Princeton NJ & Palm Springs Ca.

Re: On the ALSA Track

Anonymous's picture

Is the chip a SiS SI7012? If so it can be used under the snd-intel8x0 ALSA module.

ALSA and Xterminal? Re: On the ALSA Track

Anonymous's picture

We are experimenting with running Xterminal and replacing the workstations with thin clients. The only issue we have is with sound. It seems like although the xterminal applications run fine, the sound component is not. Our staff listen to voice mail messages from clients and we were planning to utilise gnome meeting for internal communications. All sound files accessed on xterminal
are played on the application server, which renders this setup useless. Same with Gnomemeeting.

Is there a way for setting up ALSA to work with Xterminals?

ALSA and Xterminal? Re: On the ALSA Track

Anonymous's picture

You should look at 'The Linux Terminal Server Project".
Although up-through version 3 does not appear to have remote sound on the terminal side, there is a package called "ltsp_sound", plus ltsp version 4 should have sound support built-in.
- Ken Roberts

ALSA and Xterminal? Re: On the ALSA Track

Anonymous's picture

I have considered this situation myself, and thought about some potential solutions. I am rather new to gnu/linux so standard disclaimer: "there is probably a better way but I don't know it yet"...

That said, my idea involves setting up an audio tunnel through the network before an SSH connection is established to bring the video. With my limited base of knowledge, I would assume a Perl script that creates the ports, handles logins (if necessary, depending on how you work it), and creates a new sound card file in the /dev tree that maps to the script.

In short:
- a /dev item for your sound card would map to a file or script of some sort
- a remote terminal could receive this audio
- once a connection is started you open your X environment, and map your applications to the correct "sound card"

Maybe I'm wrong... I suppose the hooks might not exist, but it seems like with some work this is a possibility.

Hope this is useful!
`RC Weal

ALSA and Xterminal? Re: On the ALSA Track

Anonymous's picture

Wrong way to try to send sound - /dev/ directory entries are for devices on your LOCAL machine - not what you want to send over the network.

Look at the Linux Terminal Server Project (ltsp - www.ltsp.org) which does have several options for allowing this.

- Ken Roberts
Slackin' since SLS-3.2
Slackware Linux

ALSA and Xterminal? Re: On the ALSA Track

Anonymous's picture

No - but that's not what ALSA is meant to do.
Look into a sound server, such as esd (GNOME), arts (KDE), NAS, or jack.

Politics of Sound

Anonymous's picture

I'm surprised you didn't mention the politics of sound.

Before ALSA, Linux sound became the free branch of a commercial product. One could BUY drivers that worked, or use OSS. This caused a lot of trouble, especially from developers that contributed to OSS and wondered if their contributions were also being sold. This free sound code began to rot, as there was no incentive ($$) to grow it.

I think (?) ALSA first started showing up in kernels from SuSe. It was quite a while, and many battles later when it replaced OSS.

author's response

Anonymous's picture

Perhaps Dev can clarify this a bit further, but I believe that OSS/Free preceded the formation of 4Front Technologies. At any rate, I did not discuss the politics of this matter because that wasn't the point of the article and because I don't like stirring up old issues. I consider the 4Front guys to be good people and personal friends; I feel the same about the ALSA folks. It's also worth noting that ALSA was not ready for inclusion with the kernel sources until recently. That seems to be the opinion of the kernel maintainers and the ALSA team.

I should also state that I very much appreciate the work done by Hannu, Dev, and many others during the OSS/Free period. Without their seminal work I might never have got into Linux at all.

Re: author's response

Anonymous's picture

OSS/Free was not before OSS/Linux.

Before 4Front Technologies got involved with the sound drivers the package was called VoxWare. Open Sound System was based on the work I had done on VoxWare. Our first task was removing any code that could cause any copyright problems.

In the beginning OSS/Free (which was first called USS/Lite) was
derived from the same source tree than OSS by running it through a simple filter. The differences between the "free" version and
the commercial version were in the user land utilities (for configuration and automatic detection).

Best regards,

Hannu Savolainen
author of the VoxWare drivers.

Re: Politics of Sound

Anonymous's picture

> This caused a lot of trouble, especially from developers that
> contributed to OSS and wondered if their contributions were
> also being sold. This free sound code began to rot, as there
> was no incentive ($$) to grow it.

I can assure you that all care was taken to make sure that the commercial OSS drivers are free and clear of any GPL violations when we split off from OSS/Free back in 1998. Prior to that OSS/Free was under BSD license.

The problem with the OSS/Free drivers is that each driver was implemented by a different programmer - while all the OSS/Free drivers work according to the OSS API, there is little consistency in the code. This made it hard to add some of the features in the commercial OSS drivers like mixer extensions that we were willing to contribute back to the OSS/Free project back in 1999.

Alan Cox did a marvellous job of maintaing the code despite these issues. But Alans' main job wasn't sound drivers - it was maintaining the kernel. So in effect, not having one central person who could control OSS drivers have given OSS/Free a bad name.

There will be some more news about OSS v4.0 (after 10+ years of OSS v3.x) in the months to come. You will see that the OSS API is not "old" after all.

Best regards

Dev Mazumdar
President
4Front Technologies (http://www.opensound.com)

Difficult to Configure Sound Driver Without OSS

Shyam Yadav's picture

I had been using OSS/linux Since a year each month its licence expire
I have to download new version of OSS and use for it on that particular period .
I came to Know about OSS/free which I couldn't able to Find any where
Anyone can help me finding OSS/free so I can Have Sound On My Linux System.

Score only 4/5 for ALSA's aims

Anonymous's picture

The problem with saying "OSS is deprecated" is that only four out of the five aims of the ALSA project have been implemented. I am referring to aim #5 ("Support for the older OSS API") which is not yet fully implemented. Until aim #5 is completed, ALSA cannot be a valid candidate for completely replacing OSS and OSS remains essential. The fact is there are major bugs in ALSA's OSS-mode sequencer which is seriously broken (http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug...). The bug report explains how to reproduce these bugs. Fortunately I think these are the only major bugs that prevent ALSA being a compatible replacement for OSS. However, it has been more than one year since the bugs were first reported to the alsa-devel mailing list (26 Aug 2002) and nobody has committed any patches to ALSA CVS or to the mailing list. The bugs are in the latest ALSA CVS and have been in ALSA since at least ALSA 0.3.0 (10 Feb 1999). I wish I knew the ALSA driver code well enough to be able to fix the bugs myself. I appreciate the work of the ALSA project and hope somebody will get around to fixing these bugs soon.Will(copied from LWN comment)

Re: On the ALSA Track

Anonymous's picture

I have to disagree with the assertion that OSS/Free applications won't benefit from ALSA. On my system, at least, the OSS/Free emulation in ALSA diverts a second client writing to the first dsp to the second dsp. This means that I can play two sounds at once without a software mixer, because the system does the obvious thing. I'm fairly certain this didn't work with actual OSS/Free (although I haven't booted 2.4 since I noticed that this was happening, so I'm not sure). In fact, I've been quite pleased with ALSA on 2.6, even though I haven't gotten around to installing ALSA utilities or libraries. From my point of view, it's just a better implementation of OSS/Free (so far).

Re: On the ALSA Track

Anonymous's picture

I'm not the author, but would like to plug another article written by Dave Phillips for the Computer Music Journal:

http://mitpress.mit.edu/journals/pdf/comj_27_4_27_0.pdf

I'd like to start using GNU/Linux as an audio platform and found it a very useful summary of the current state of audio on Linux.

Before reading that article I found it quite frustrating trying to get information - is there a central source for Linux audio that's comprehensive and up to date?

Even basic stuff such as which soundcards to use hasn't been as simple as I'd hoped - the driver information on the ALSA site is pretty minimal IMHO - at most there might be 4 or 5 comments on a particular driver. Ok, I suppose that merely reflects the fact that pro audio on Linux is relatively new. I'm hoping that a M-Audio Audiophile 2496 will be a good choice (would love an RME, but too much cash).

Anyway, thanks for these articles Dave - without them I probably would have given up!

Re: On the ALSA Track

Anonymous's picture

Well, I'd say that Dave Phillips site is the central source for information about Linux audio. There's also the Linux Audio Developers/Users mailing lists, and the ALSA mailing lists.

Re: On the ALSA Track

Anonymous's picture

Yeah, I think you'd be right there - not quite sure how I missed it yesterday :)

I'd recommend the ALSA mailing lists in particular - answered everything I needed to know.

Thanks for posting these links.

Re: On the ALSA Track

Anonymous's picture

I've got a M-Audio Audiophile 2496 card and it sounds really great.
I'm using SuSE 9.0 and it's all good, make sure you install the envy24control program.
I've been running my 12 track through it with good results. I am hoping to download Ardour once a 1.0 binary is available and hopefully use my 12 track as a midi control device, using the 2496 card. But that's another story :)

Care to post your .asoundrc?

Anonymous's picture

Care to post your .asoundrc?

Re: On the ALSA Track

Anonymous's picture

Thanks - having looked at the ALSA mailing lists it seems others agree with you as well :)

I've tried getting Ardour up and running on my stock Mandrake 9.2 without too much success (not too surprising given the (non-existent) quality of my current hardware) - looks like one of Agnula/Planet CCRMA/Turn-key is the sensible way to go once I get the card!

Re: On the ALSA Track

Anonymous's picture

I would definitely recommend Planet CCRMA. Using APT to update not only system packages but also the tons of quality third-party packages (such as Ardour) is sheer bliss.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix