three ways to install alsa drivers

One thing I’m noticing a bit of confusion on in general online is what the docs or me mean when it says to install the ALSA sound card drivers as modules.  So, lemme clarify real quick. 🙂

There are two *places* to get the drivers from: either in the kernel, or from the alsa-driver package.  But, when using the kernel drivers, like many other drivers there, they can either be compiled in statically or loaded as modules as the computer is booting up.  So, there are actually two ways to install the drivers as modules, which could be a bit confusing.

So, a quick list:

1) In-kernel drivers (statically compiled)

2) In-kernel drivers (modules)

3) External drivers (alsa-driver package, modules)

The first two are the officially supported methods by the ALSA team, so I’ll quickly focus on those two.  Now the, recommended way to do things is #2 — select them as modules in the kernel and build them that way when you are setting up ALSA for the very first time.  Why?  Well, the answer is really that it gives you a lot more options.

Let’s say, for instance, that you aren’t sure which driver your card requires.  So, you flip on a few that look like it’s the right one, and set them to be installed as modules.  Once they are there,  you can run alsaconf, which is a part of alsa-utils.  The alsaconf program will do the detective work for you by looking at the modules that are available on the system, and the cards that you have on your box, and then load the modules and update your module list so that they will load up the next time you boot your box as well.  Pretty simple, right?  It sure is a lot faster than compiling one driver in the kernel, rebooting, testing if that works, trying a separate one, rebooting, etc.

Another reason is that there may be some options you need to pass to your module.  This is rare, but it does happen.  If you are loading them as modules already, then it’s just a simple tweak to do change the settings, again, without having to reboot and re-test everything.

So, that’s the reason we recommend you load them as modules.  It’s just gonna make life a bit easier the first time around, as you are trying to determine what you have.  Once you know what driver is required, you can always go back into the kernel and compile it in statically, and be done with it.  There’s no reason to keep it as a module, unless you want to.

Finally, a quick note about the alsa-driver package.  It’s often said that it is unmaintained, and the reason for that is because I, personally, am the only one who is keeping it on life support.  That is, I’m the maintainer, not the ALSA herd.  It’s only in the tree as a convenience to people who need to use it for whatever reason.  Some of the reasons could be that you needed to see if the latest release from upstream is fixing some issues of yours, so you’d use the live ebuild.  Or, you may want to use an older kernel but still keep the newer version of ALSA.  Or whatever.  The problem, though, is that I don’t have the technical skills to troubleshoot your issues if something goes wrong.  My solution every time is  pretty much going to shrug and say “Sorry, that sucks.  Try the live ebuild, or something else.”  It’s not that I don’t want to help, it’s that in this case, I can’t.

Anyway, that’s it … I hope that clears up a few issues.  When I have time, I’ll be revising the ALSA docs.  No idea when that’ll be though.  Don’t hold your breath.  In the meantime, if you have issues, my recommendation is to post on the Gentoo Forums in the Multimedia forum and ask for some help, or there’s always bugzilla.  Chances are you’ll get a response faster on the forums, though.  Good luck, and God speed. 🙂