I wish to thank the users who submitted comments about my previous entry to ask me not to make the alsasound init script only handle levels; this is the kind of feedback I needed, as this allowed me to assess the problem: I cannot do that. I talked with Roy though, so I’ll be working on a solution in the next days.
What are the problems? First of all, I need to fix alsa-util with a new init script, that would support being run by udev, in which case it totally forgets about loading modules and only takes care of loading the status. The reload method (versus restart) would reload the levels, while restart would take care of removing and inserting the kernel modules back.
The problem to put this in practise is that during restart I don’t know if I have to load the modules statically, or if I have to leave them to udev. Right now the init script actually implements some sort of basic coldplug, that sucks to say the least, especially with respect to complexity.
I wonder if making the alsasound init script only take care of modules if they are static, rather than coldplugged, would make sense. This way it should be pretty much transparent to everybody, although using snd-card-0 should still be deprecated.
I’m tempted to either get a conf.d file where users can provide a ALSA_MODULES variable to load X Y and Z drivers, or to leave the users to use modules.autoload.d and search for ^snd.* on that file during restart.
Suggestions are welcome, handling this more transparently is probably a good step forward toward user friendliness, and I want to be able to get this working before 1.0.15 possibly 🙂
Oh yes, the midi useflag is now enabled by default, and present in alsa-driver too; by disabling it you can also disable sequencer modules from ALSA, which is a decent save of kernel memory probably.