Slashdot Mirror
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""
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?
One of the biggest turn offs for new users to Linux is the general lack of sound support which either
1) Requires recompiling the kernel and crossing your fingers.
2) Requires you to use the beasts known as ALSA and crossing your fingers.
Operating systems are no longer stale command prompts with beeps and blurps -- they are full mutlimedia systems, and having working sound support in the first install should be a priority for Linux distributions.
When Linux newbies have a lack of HOWTOs and sound support is diffuclt to implement, at best they are going to fool around with Linux for a day or two and then go back to their MP3 collection under Windows.
Sound card detection and setup happens invisibly and automatically on several other distributions. Why is this article worth mentioning? What would actually be newsworthy would be some Debian people swallowing their pride and incorporating some of the excellent automatic hardware detection, setup and installation routines that the other distro developers have produced. That's what free and open software is all about, right?
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-(
I have 3656.9 Bogomips. How many Bogomips do you have?
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?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
What's wrong with that approach? Let's see:
You don't learn anything. Learning new things is important to me, if not to anyone else.
Automagically detecting hardware is not an exact science. If all you use is a tool to do something, then you can't fix it if said tool breaks.
Lots of time to read is relative. In the time it takes to read the HOWTO, you could have read the documentation that comes with ALSA and walked away with far more knowledge. You have to learn how to do anything, that's just a fact.
SealBeater
-- Its survival of the fittest...and we got the fucking guns!!!
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
- Make sure you have a 2.5.x kernel or above.
- Select your card from a dropdown.
- Retrieve, unpack, and compile source code.
- Install resulting software with a strange command-line utility.
- Retrieve, unpack, and install even more software.
- Edit a configuration file.
- Edit another configuration file.
- Run a script.
- Start a daemon.
Wow. That's so easy! I can see why OS X is the number one selling Unix:
- Go to System Preferences.
- Select "Sound".
- Select "Output".
- Select your high-end audio card.
- Select "Input".
- Select your high-end audio card.
Let's assume that your time is worth $50/hr. After a few hours of struggling to set up sound under Linux, that extra cash for Apple hardware doesn't sound so bad...
It has ALSA built in.
Compiling your own kernel additions is for experimental stuff, not stuff that has been working for years like ALSA
It has killer package management (Portage! -- what other package manager lets you specify compile-time options?)
Dunno if you've heard of it, but there is a package manager called RPM that lets you set compile time options when you are building from source packages.
I'm sure alsa does lots of cool things, but I never got past the fact that with the oss drivers, I could:
:) WTFIUWT?
$ modprobe es1370
and away I went.
With ALSA, I could load 15 or twenty drivers, and even if I managed to pick all the right ones, the damn things were muted by default!
So.. maybe a howto is a good thing. But why is it so damn complex that it requires a howto?
If your distro picks up, configures and sets your sound up without ALSA then you do NOT have to do this. You can and ogle for playing DVDs requires it but personally on my maestro3 card the sound from the OSS driver is better IMO compared to ALSA.
_ __
In ALSA it sounds sort of tinny and strained, it seems like the plain-jane maestro3 as opposed to the ALSA snd-maestro3 works better at least on my laptop.
I never seem to have trouble with my sound till I start mucking with it by hand. If I accept the distro defaults I am usually better off. This is a good thing for distros by the way. However, this is the exact opposite in terms of XF86Config. It seems like I always find two or three things to tweak manually that the distro-makers miss.
Oh well...
_______________________________________________
ACK
I can't see how this is newsworthy, it's already in your /usr/share/doc/alsa-source/README.Debian.gz. And they use the far simpler make-kpkg instead of building manually with lengthy vars to define that nobody remembers. ;-)
Ok, the big news was indeed: use apt-get install alsa-source and read the manual to get alsa to work on Debian
have you been defaced today?
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.
-fb Everything not expressly forbidden is now mandatory.
Many of you may be wondering, why ALSA made front page news. There are several reasons:
1. ALSA sound drivers are nearly impossible to install.
2. If you want to turn your Linux box into a PVR (Personal Video Recorder) ala TiVo, then you need the alsa drivers and the stuff from the GATOS project.
(See) http://gatos.sourceforge.net/overview.php
I am glad that someone posted the HOW-TO... Alsa has been a big thorn in my side for awhile now. Maybe now I can get the ALSA-Mixer working properly.
Good Luck, and may your all Linux boxes be PVR's!
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.
Kid-proof tablet..
For those interested in setting up alsa, note that the modules options file in the article is only valid for alsa 0.9 up to rc3
/etc/modules.conf files by hand or use our alsa-driver/utils/module-options script which does this job. Please, notice that 'snd_' prefix is not equal to 'snd-' prefix (module name) which is left unchanged.
The line
options snd snd_major=116 snd_cards_limit=4 snd_device_mode=0660 snd_device_gid=29 snd_device_uid=0
wont work with newer versions (for instance Sid has 0.9rc5, an so I guess Testing will have it soon too), because (from www.alsa-project.org)
We have changed the kernel module symbol names (module parameter names). We removed prefix 'snd_'. Please, update your
That means you need to change the previous line into something like:
options snd major=116 cards_limit=4 device_mode=0660 device_gid=29 device_uid=0
Hope this helps
!
^_^
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.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF