Installing/Configuring ALSA Sound Modules In Debian

GonzoJohn writes "Linux Orbit explains how: "A very common question that comes up when trying Debian GNU/Linux is how the heck do you get Advanced Linux Sound Architecture (a.k.a. ALSA) sound modules set up properly? In this HOWTO we'll show you how to compile and install the ALSA kernel modules, and then setup things using the ALSA Debian script so that modules are automatically loaded and unloaded, and your mixer levels are saved and restored on boot up. Here are some things you'll need to have before you start this HOWTO""

Comments

Wow...

[delta407]

Gentoo Linux has had a similar guide for months, without coverage on the front page of Slashdot. (And, if I may say so, the Gentoo way is cleaner.)

Maybe I'm missing something, but why/how is this news?

NOW they have a HOWTO....

[PigeonGB]

I spent a week getting sound to work on my system by using Google and experimenting. Then they decide to make it easy so that my accomplishment would mean nothing to all of the newbies who show up.
I can hear/see it now:
"Hey guys, do YOU have sound on your system? I do!", I exclaim, with beaming pride.

"Uh, yeah whatever dude," they would say. "I got sound working too. Dumbass."

I can no longer consider myself 1337. B-(

Nice Article. Audio in general

[billstewart]

I've just installed Mandrake, and I need to decide which of the El-Cheapo Pretends-To-Be-Soundblaster-Compatible audio cards I've got I should install, so the timing is really convenient for me. The ALSA folks rock, compared to the quality of driver support for soundcards on Linux in the past.

I'm also evaluating getting a better audio card, but I've had trouble finding decent documentation, even on the boxes - sure, everything does eight-dimensional 12-in-1 audio output, but what's I'm more interested in is the quality of the A/D converter, so when I input sound from analog media (my old vinyl disks and analog tapes) it doesn't lose more than necessary. Are there chipsets to avoid, or to hunt around for?

Re:Why is this newsworthy?

[PigeonGB]

It isn't about pride, as much as the number of Debian users would make it sound.
It is more of the fact that Debian can't release a new Stable version until it works on all of the supported platforms.

But you are right. There should be no reason why something like autodetection shouldn't be incorporated into the install process. That is why they are working on a new install/boot process. An active mailing list to be on, let me tell you.

Re:RTFM....

[m0rph3us0]

Umm... this how-to appears to be very well written, in fact much better written then the lack of documentation that comes with the package, the last time i setup ALSA it took me about 48 hours mainly because no where was it clearly explained how to do things, it was read as much documentation as you can and try to make up the manual yourself based on what you know from the API. Essentially this how-to is now the manual

Mandrake doesn't need a guide

[dan the person]

It has ALSA built in.

Compiling your own kernel additions is for experimental stuff, not stuff that has been working for years like ALSA

"getting sound working" is not the whole story.

[fishbowl]

Since most people only want sound hardware for output, this is probably enough.

If you are looking to migrate away from Cakewalk, Cubase, or Logic to a Linux solution, it's still a pipe dream. Sure there are a million audio projects, but the cubase killer is just not out there, not in the pipeline, and I don't even imagine it's in the cards.

A linux version of Fruityloops would be awesome, and if it were able to host VST applications, it would be of significant value to me.

One other point; I'd like to see a howto that deals specifically with the 2.5 kernel and debian.

The article is clear and concise, and it stops short of telling you how to, say, do multitrack recording, enabling 24/96 recording and mixing, or how to enable hardware synths. It also doesn't give any card specific help (Ice1712 M-Audio cards, anyone?) This is really just a special case of "installing modules" which is documented pretty well, elsewhere.

Re:Nice Article. Audio in general

[adolf]

If you're really quite serious about A/D quality, look into using an external box for the task. Midiman makes a couple of different, well-performing 24-bit models, and they occasionally pop up on Ebay. Or, you could pick up a nice pawnshop/Ebay DAT or Minidisc deck, and use that.

Not that you need 24 bits to transcribe vinyl, but it does help ensure that you'll not run out of headroom. Later in the process, you can normalize the audio and truncate or dither it down to 16, while preserving every nuance of the album's pops, ticks, and surface hiss.

Plug a box like this into a sound card's SP/DIF input. The stupider, cheaper, more DSP-phobic cards will generally be more likely to do a bit-perfect job of this, such as the $12 Zoltrix Nighingale or other CMI8738-based cards. Along the same lines, do try to avoid anything branded Creative Labs, mmkay? They've got bad habits like irrevocable resampling, and are noisy throughout (even when only doing strictly "digital" things with SP/DIF IO).

That said:

I used to play engineer for a streamed talk radio show. Equipment was limited to the gear in a small project recording studio, none of which was intended for broadcast use, aside from the scrap-built Linux box running liveice and lame.

Since this box needed a sound card, I drove over to the nearest white-box OEM parts dealer and started looking. I picked a YMF744-based (XG) PCI card from AOpen, similar to this one, based primarily on the component count: It was the only card under $50 which was not branded Creative, and appeared to have reasonable analog filter stages and signal paths.

It turns out that this card, along with other Yamaha XG cards, has superb support under ALSA, and that the quality of the converters is not bad.

The control of the card was such that I was able to calibrate it to the output meters on the Tascam console, and monitor the program via digital loopback through its own DAC at 0 gain.

I could then push a button on the console, and switch between monitoring the signal in its original analog state, or after it'd been through a ADC->DAC stage without worrying that varying levels would skew my perception.

In the (somewhat noisy) enviroment I was in, I could hear no difference in overall quality with or without the Aopen card in-line. This cheap sound card was, in a word, transparent, at least for my purposes. Which is all I can ask of any sound card.

ALSA made this easy, but I suspect I'd have trouble doing things so precisely under other operating systems.

But I've noticed that not all XG-based cards are made the same. Hoontech sells, or at least sold a year or two ago, some expensive studio-oriented monstrosities which doubtless sound beautiful. On the other end of things, I've heard some laptops with XG chips which sounded horrible.

Lately, I've been recording my 2-year-old daughter's various noises with an SB Live 5.1. The results are OK, but nothing like what I remember hearing in the studio. I could blame the card's on-board mic preamp or the sound of my apartment, but I fear that shoddy AD plays at least as large a role in the matter.

Good luck.

You gotta hate Linux

[Directrix1]

Why does linux make everything so damn hard. I use linux, but only because I believe in free software and right now its the only real provider capable of doing what I want to do. But it is so outdated it just bugs me. Somebody needs to take these suggestions, and actually think for a second about how much better linux would be if they were just implemented (also I have running about 4 linux desktops and 2 linux servers, so I'm not a super mega linux geek, correct me if I have an off point here):

1) Why does everything have to be compiled into the kernel. What? Can the kernel not map shared objects into its memory space? And if it can't, why not?

2) Why don't they establish only standard APIs that device drivers have to implement (seperate of the kernel and not built into some stupid x-windowing system or something irrelevant to what it does example: sound drivers for KDE), i.e.:
OpenGL - graphics library
OpenAL - audio library
insert appropriate nic standard
insert appropriate printer standard, etc. and make the stupid x-windowing system just another interface that runs on top of OpenGL, jeez.

3) The everything is a file mechanism is really getting outdated. Why are there not object oriented shells yet? Come on, just pop a javascript shell in there, make ObjectInstantiators/ObjectSerializers that detect file types and convert to the appropriate object instance, so javascript can instantiate it, use it, serialize it back to disk, and then move on.

4) Why do we still use program based architectures? Programs are way too linear. We need objects and an object handling mechanism (like javascript or something similar to it, like a Delphi UI or something) not programs. Once you make a program things get hard coded in that make it too specialized to be used in anything other than what it is designed for, if everything was just an interactive object, you could chain them together and do all sorts of neat tricks, that you could never dream of with standard file based shells/programs. And then you could serialize these object webs you create to disk for use as kind of a template(I'd say program but you could easily modify these to fit your needs). Sounds way better than standard file based scripts to me. Although javascript scripts sound nice too.

5) If we are going to be using a program/file based OS, lets make the program names intelligible. Lets see: vi, emacs, joe (joe??? what the hell man), yast, lilo, initrd, sh, etc., etc.. Come on guys name your programs something intelligible, and leave the credits in the fscking readme file. At least if dos had something it had convenient keywords (copy, rename, delete, deltree, EDIT). I realize I could make symlinks to my hearts delight, but that is only assuming you know what the program your looking for is called.

6) Why did anybody think it would be a good idea to integrate the inetd with the x-windowing system (xinetd). Yippee, all the speed of NT servers on a linux system. Of course thats assuming you use inetd to begin with.

7) This one is for the distros: quit using the damn graphical installers. Graphical installers don't make installing any faster (quite to the contrary in a lot of cases), and in installing on older hardware a lot of times it makes it nearly impossible. I'm all for straightforward installers, but you don't have to be in a graphics mode to do it (fine standard VGA modes will work)

8) Hey I got a fun idea, lets put all those binaries in one directory, with no real index as to what each of these programs with obfuscated names do, and then lets give no easy way to find out what it does short of running it. Woo! And don't say, "One word, man" or "info" those systems are pretty fucked up as it is.

9) Standardize the damn locations, follow the LSB biatches.

10) This may sound contradictory to the above, but... abolish the Unix file system layout. I can't stress enough how a simple object persistence/serialization mechanism would be way better than a file system any day. Anyways, those are just my rants/suggestions as to what needs to be changed or layered on top of the linux filesystem if they wanted it to actually be a BETTER OS than windows or MacOS.