At the moment, ALSA is purely initialised in scripts, and the alsasound script has to be added to runlevel "boot". I think this is inappropriate, and have a fix... Modules.conf has a very large and flexable syntax, enabling you to do all sorts of stuff. Devfs will autoload modules on demand, by calling modprobe with the name of the device to be loaded. alias lines in modules.conf can therefore be used to autoload the sound modules, and post-install/pre-remove lines to enable the saving and restoring of sound levels.
Created attachment 4278 [details] exerpt from modules.conf to autoload oss-compat modules Placing these lines in /etc/modules.conf (normally by putting this file in /etc/modules.d and running /usr/sbin/update-modules) will enable you to remove the ALSA OSS modules from modules.autoload, and to put alsasound in the default runlevel. The OSS modules will be loaded on demand.
Currently the OSS modules are loaded on-demand (if you have them in modules.autoload, then you probably added them there yourself). Most of the lines in your suggested modules.conf are already installed via /etc/modules.d/alsa; actually, all but one line as far as I can tell. And that's the line options snd snd_major=116 snd_cards_limit=1 What exactly does this line do? Also, why do you think that this is inappropriate to have alasasound script in the 'boot' runlevel?
Well, if the OSS modules get installed on demand, then there is no need for the alsasound script to be in boot... It was my understanding that the reason for putting alsasound into the boot runlevel was that you would need to put the OSS modules into modules.autoload -- that was certainly the case when I last installed alsa. I added the OSS loading lines into /etc/modules.d/alsa to get around having to do that. If they are in there by default now, then there's no need to that big yellow notice telling people to put stuff into the boot runlevel :-) Trust me not to notice someone fixed the bug without updating the docs... And I don't want it in boot because I don't (necessarily) want alsa to start at boot -- if I go into a runlevel other than default, I don't want alsa. Boot should only be for things that the system *needs* to run. Else why bother with different runlevels at all? (BTW, the extra line sets the major number for sound devices, and limits the system to using only one device -- probably not required... in there because it used to make a difference to me) I've not got anything in my modules.autoload (except for network modules), and alsasound is in runlevel default, working perfectly. My ideal situation, seeing as I have devfs working fine, would be to autoload ALSA as well, but I've not got that working yet. I'm guessing that one would be something to handle through the ALSA folks though, not here. Thoughts? Thanks, Andrew.
The reason alsasound is in 'boot' runlevel is because I want this script to be executed *before* any modules are loaded from modules.autoload (see the line "before modules"). The script "modules" is in the boot run level by default. If you don't have anything in modules.autoload, then you can probably safely place alsasound into "default" runlevel. Having "alsasound" to go into "default" by default will result in too many people shooting themselves in the foot (e.g. by placing some oss modules in modules.autoload). That said, I agree that in an ideal world alsa-sound would go into the 'default' runlevlevel.
Can I close this one?
Wouldn't marking it as either "invalid" or "wontfix" be better, as you haven't actually done anything as a result of the bug?
Erm... have to reopen it, then.
Resovling as wontfix.
