Friday, July 26, 2024

Better Linux Sound Management With ALSA

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Part 2 of “Webcams in Linux” is going to appear later, as there are a number of kinks and roadblocks to work out. So today we’re going to dig into ALSA, the Advanced Linux Sound Architecture, because I think it’s the best tool for managing your Linux sound devices. It’s good for managing multiple sound devices, and it works in all Linux environments including other window managers, or no X Windows at all.

Yes, I know that Gnome has ESD (Enlightened Sound Daemon), and KDE uses aRtsd (analog Real time synthesizer daemon). Aside from the annoying problem of having to cope with multiple sound subsystems, both ESD and aRtsd introduce complications, such as conflicts with ALSA and latency. Latency is the enemy of sound quality, especially over a network. So when you’re streaming audio (either by itself or with video), using a software IP phone, or playing online games the first thing to do is turn off ESD or aRtsd and use only ALSA.

So what’s up with Webcams? As one reader told me, is “the state of Webcam support in Linux is nasty and brutish.” The core problems stem from lack of support from hardware vendors (get in the 21st century, folks, geez!) and inconsistent Video4Linux support. Video4Linux is the video capture API for Linux. All video capture devices and applications must use Video4Linux. That doesn’t sound too bad, as it is just a single API, and as far as I know the only one. But there are two versions: the original V4L, and version 2, sometimes (but not consistently) called V4L2. Version 2 is substantially different and improved from version 1.

Virtually all modern webcams require V4L2, but some Linux applications and camera drivers still don’t support it. Support in some applications is so new it’s not in distribution repositories yet, so you have to build from sources to get V4L2, and you usually have to read the Changelogs to figure out what’s going on. It’s understandable that an unfunded overworked FOSS project would have problems with this, but get this- Adobe’s Flash Player for Linux does not support V4L2. (And still no 64-bit version.) This makes live Internet streaming a problem- you can’t use sites that host your live streams for free like Ustream.tv, Justin.tv, and Stickam.com, or use free video chat and phone like Tokbox.com because they depend on Flash. So your options are to use an old lower-quality camera that supports V4L version 1, or to capture and host your own streams. Let’s have a big cheer for proprietary innovation! Or in Adobe’s case, enervation.

You’re going to need alsa-base and alsa-utils. Suppose you have a single sound card on your system; either a PCI sound card or onboard sound. This is easy. Just fire up alsamixer to configure it, as Figure 1 shows. That’s for my onboard AC97-based chipset. (As always, lscpi will show you what’s on your system.) alsamixer only displays supported functions. The top-left captions tell you a lot of useful information: your sound card and chipset, which set of functions you’re viewing, and the values for the highlighted setting. The default view is Playback, like in Figure 1. There are three views: Playback, Capture, and All. Hit the Tab key to toggle between them. Figure 2 shows the Capture screen.

Basic navigation and settings are easy: go back and forth with the right and left arrow keys, and hit the Escape key to close. The little boxes with MM in them means that function is muted, or disabled. Toggle the M key to mute/unmute. 00 means zero volume, so use the up and down arrow keys to adjust it. When there are two channels you can adjust each one independently, which you can see in the Master setting in Figure 1. Q increases the left channel, and Z decreases. E and C control the right channel. In the Capture screen, use the spacebar to select the active recording device.

Most of the settings are self-explanatory, but there is oft confusion over Master and PCM. Master controls your playback volume. A PCM device is like a virtual soundcard; this is the bit that converts analog sound to digital. It can be either software or hardware. Your Linux sound applications need the PCM channel. So you usually need both of these active to enable playback.

What if you have two sound devices? In alsamixer, hit F1. This displays basic commands. F2 displays various /proc/asound outputs related to sound all in one screen. Figure 3 shows I have two sound devices, 0 and 1. F1 takes you back to the menu, and the Return key closes it. To configure the second sound device, close alsamixer by hitting the Escape key, then reopen it like this:

$ alsamixer -c 1

-c means card number. A quick way to test your sound is with aplay:

$ aplay -d plug:dmix yoursoundfile.wav

When you have multiple sound devices, your various applications (such as Skype and Ekiga) should have their own configurations for which devices they’ll use. Next week we’ll learn how to test individual channels, and how to use the recording functions for various tasks.

Resources

Carla Schroder is the author of the Linux Cookbook and the newly-released Linux Networking Cookbook, and is a regular contributor to LinuxPlanet.

This article was first published on LinuxPlanet.com.

Subscribe to Data Insider

Learn the latest news and best practices about data science, big data analytics, artificial intelligence, data security, and more.

Similar articles

Get the Free Newsletter!

Subscribe to Data Insider for top news, trends & analysis

Latest Articles