[gentoo-amd64] Re: Alsa Config keeps disappearing

[Duncan]

sean <tech.junk@×××××××××××.net> posted 4A492614.1050603@×××××××××××.net,
excerpted below, on  Mon, 29 Jun 2009 16:37:40 -0400:

> I use xine for both CD and DVD, and a xine-out.wav is generated if
> alsaconig has not been run again after a system startup.

This sounds to me like one of the sound modules isn't loaded.  ALSA has 
always started muted, until it's unmuted, but that can't be it, as xine 
should then play, it'd just be muted.  But if one of the necessary 
modules wasn't loaded, xine would presumably detect that by the failure 
to open the device at all, thus the xine-out.wav.

But running the config loads the modules, which apparently are NOT auto-
loaded by the alsa service or whatever you have running at start to bring 
back sound -- that's assuming that you DO have something running to load 
sound at start.

FWIW, I've never had an issue of that nature here.  For quite some time I 
didn't run the alsa service at boot, since I only used sound in KDE, and 
KDE would start it when I started KDE.  However, when I switched to an 
mpd based music system, I switched to starting sound at boot, and it 
"just worked".

BUT, my kernel policy has for YEARS been to build-in everything possible 
that I use enough to keep loaded.  Stuff like the floppy and loopback 
drivers don't get built-in, as I very seldom use them and thus might as 
well not load them unless I DO use them.  But all my sound drivers get 
built-in, because if I'm loading them at boot and never unloading them, I 
might as well.  So presuming the problem is what I think it is, I 
couldn't have it here, because the sound drivers are built-in, not loaded 
as modules, so they're always loaded.

Of course, that can get a bit complicated for those drivers that need 
parameters fed to them at load.  Loading the modules is then easiest.  
However, most of them can have the parameters fed to the kernel directly 
on the kernel command line, as fed to it from grub (or with newer 
kernels, 2.6.29 maybe??, from the built-in kernel commandline option, 
which sure simplified /my/ grub kernel line!).  The problem then is 
finding the documentation telling you exactly what form to use on the 
kernel commandline, since the options take a bit different form there, 
including the driver name, etc, as it's otherwise not obvious what they 
refer to.  But in most cases it can work, you just have to find out 
exactly what to feed the kernel commandline.

So that's what I'd suggest.  If your sound card drivers do NOT require 
driver commandline options, build them in.  If they DO, it's a bit more 
complicated as you'll have to find documentation covering the exact 
format of the kernel commandline options to feed, but look around in the 
kernel documentation dir and do some googling and see what comes up.  If 
you can find what to feed the kernel, do so, build-in the drivers, and 
that will hopefully eliminate the issue.  Of course, this assumes that 
you are loading the drivers at boot and not unloading them, so building 
in the drivers doesn't increase the running size of the kernel 
uselessly.  But I expect that's the case for the folks having the problem 
here, or they'd already be used to loading and unloading their sound 
drivers as needed and thus wouldn't be having the problem with the 
failure of the automatic system to load them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman