rmmod and insmod are almost the same as modprobe -r and modprobe. With a configuration, modprobe -r will remove the module and other modules attached to it. And modprobe will load a module and depending modules. rmmod and insmod are a bit more primitive, in that you have to do it for each module. And since snd- modules have a sequence / dependancy tree, you have to insmod in a particular order or it fails. From the lsmod output, a module has to have 0 (not in use) and no modules listed to the right of the 0 to be successfully rmmod'd. The only other number column is the size of the module in bytes. The insmod sequence is the reverse order of the rmmod sequence. It's a pain, but functionally tedious when the larger picture is obscure or left unconfigured. It was mildy more understandable when alsa was not part of the kernel tree and you would compile alsa specific to only your soundcard. So only the modules you needed were listed in the alsa-driver/modules/ location, all 18-ish of them at that time.

Since the modprobe -r failed, you're likely missing some configuration elements. In days of old this configuration allowed module loading and unloading when used / left idle. It might have also failed because the module was in use (pulse, web browser, other sound application).

Something like that in a file /etc/modprobe.d/alsa_custom.conf
(that is where I put mine anyway)

Where the index=0 line is, is where you'd put the module parms to have them done at boot or when the module gets loaded. You can also pass parameters at boot time for things that are not modules. Normally the kernel line in grub and the module.parm=value type parameter. snd-es18xx.irq=10 would be one possibility. I used to use things like that to disable mouse touchpad extras (so annoying).

altho a command of lsmod | grep snd may have given the same results I would like to show copy and paste of Colin's output
Hopefully Shadow_7 will agree and comment on the items?

ITEM 1 line has formula MODULENAME id (number of dependencies) (list of dependences)

ITEM 2 sound_firmware is here?

ITEM 3 sb normally means soundblaster

ITEM 4 see this line "snd_es18xx 22995 1"
that looks like an error, its missing one dependency

ITEM 5 line soundcore 5025 2 sound,snd looks ok but then sound which contains sb_lib and drilling down snd shows snd_opl3_lib

ITEM 6 on my debian system the line for soundcore only has one dependency of snd
------google shows http://www.spinics.net/linux/fedora/.../msg06817.html

ok umm you still have a blacklist, please remove it and report if you can see any difference to my short list of lsmod please

that might be the reason why we have a missing dependency.....but I am struggling

Removing the blacklists did not (seem to) change anything after reboot.

Although the problem is still unsolved, I'd like to thank all of you who gave their time trying to help. I'm convinced the key is somewhere in some of your answers and need to study everything over again. Let's things rest for a while. If I find the solution a report will be published on this forum.

Kind regards to all,
Paul

The 1 at the end means that it's in use (by 1 thing?). When it's 0 you can modprobe -r or rmmod the module as it should not be in use. Nothing to the right of the 1 means that you do not have other things that you must rmmod first. But the 1 means that it is in use. By pulse? By a browser? By your desktop? By other modules? Hard to say.

$ lsmod | grep -i "snd"

The old school manual way is that anything with a "0" in that certain place, and nothing to the right of it, can be modprobe -r or rmmod'd. With regards to snd_ prefixed modules for alsa in our case. When snd_es18xx has a 0 from lsmod you can modprobe -r or rmmod it. With a "proper" alsa configuration you can just use modprobe with or without -r and it figures it out. Of course rmmod also has a --force option, if your kernel is configured a certain way or other quirks. And with alsa-utils if you /etc/init.d/alsa-utils stop, it should (in theory) remove all loaded sound modules. Thus allowing you to reload them (with preferred parameters). But that's just as likely to fail without a proper alsa configuration (that /etc/modprobe.d/ stuff).

If you've fiddled "too much", you can reinstall packages.

# sudo apt-get install --reinstall <package>

$ dpkg -l '*alsa*'
or
$ dpkg-query --load-avail -l '*alsa*'

To identify the names of the things that you might want to reinstall. Depending on what distro and how old it might be. The latter being the newer-ish way. The apt-file package and abilities is another useful way to find things. Not installed by default in many cases.

Hi

I hope you don't give up easily as I don't.

Let me re-order one of your posts to show a dependency order list
Now for your consideration
Since your sound is not working correctly, I suggest its safe to try below

copy and paste this box and name the text file remove.sh
Now we make it executable
Then before you decide to run it, let me explain why to run it first eh?
We are seeking a way of booting up----with NO blacklist sound modules
We are seeking then to remove all sound modules so we that we can
load (modprobe) your sound module but each attempt use a slightly different set of parameters
----such as irq for 5 or 10, various dma settings various port settings

If you are prepared to do it, I would like first to know if the script works by you running the remove script first with root powers and then checking you have lost all sound modules with
I don't use a sudoers list so I would do this
good luck

Done, and I've put the "remove.sh" file in "/bin" folder.

Here you can follow what I did:

[paul@localhost ~]$ lsmod | grep snd
snd_es18xx 22995 1
snd_pcm 60282 1 snd_es18xx
snd_page_alloc 5837 1 snd_pcm
snd_opl3_lib 7218 1 snd_es18xx
snd_timer 15343 2 snd_pcm,snd_opl3_lib
snd_hwdep 4844 1 snd_opl3_lib
snd_mpu401_uart 4975 1 snd_es18xx
snd_rawmidi 14818 1 snd_mpu401_uart
snd_seq_device 4321 2 snd_opl3_lib,snd_rawmidi
snd 43879 10 snd_es18xx,snd_pcm,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device
soundcore 5025 2 sound,snd
[paul@localhost ~]$ su
Password:
[root@localhost paul]# .remove.sh
bash: .remove.sh: command not found
[root@localhost paul]# /bin/ .remove.sh
bash: /bin/: is a directory
[root@localhost paul]# cd /bin
[root@localhost bin]# .remove.sh
bash: .remove.sh: command not found
[root@localhost bin]# remove.sh
ERROR: Module snd_es18xx is in use
ERROR: Module snd_pcm is in use by snd_es18xx
ERROR: Module snd_page_alloc is in use by snd_pcm
ERROR: Module snd_opl3_lib is in use by snd_es18xx
ERROR: Module snd_mpu401_uart is in use by snd_es18xx
ERROR: Module snd_rawmidi is in use by snd_mpu401_uart
ERROR: Module snd_hwdep is in use by snd_opl3_lib
ERROR: Module snd is in use by snd_es18xx,snd_pcm,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device
ERROR: Module snd_seq_device is in use by snd_opl3_lib,snd_rawmidi
ERROR: Module snd_timer is in use by snd_pcm,snd_opl3_lib
ERROR: Module snd is in use by snd_es18xx,snd_pcm,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device
ERROR: Module soundcore is in use by snd
[root@localhost bin]#

Don't ask me why, but the script runs into the above mentioned error messages.
I'd like to add that no application was playing a sound as far as I know although the system seems to believe otherwise.
What's up doc? ;o)
Kind regards,
Paul

I really can't say because no application is playing a sound as far as I know.

[paul@localhost ~]$ lsmod | grep -i "snd"
snd_es18xx 22995 1
snd_pcm 60282 1 snd_es18xx
snd_page_alloc 5837 1 snd_pcm
snd_opl3_lib 7218 1 snd_es18xx
snd_timer 15343 2 snd_pcm,snd_opl3_lib
snd_hwdep 4844 1 snd_opl3_lib
snd_mpu401_uart 4975 1 snd_es18xx
snd_rawmidi 14818 1 snd_mpu401_uart
snd_seq_device 4321 2 snd_opl3_lib,snd_rawmidi
snd 43879 10 snd_es18xx,snd_pcm,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device
soundcore 5025 1 snd
[paul@localhost ~]$

I've been very careful, but maybe worth considering.
Kind regards,
Paul

damn then I have the module order wrong.

I would still like to know why firmware is being loaded.

That's a question I can't answer.

ok

that dependency of lsmod for snd es** is a deep pit for me in my module remove script

staying with Debian maybe you could consider seeing if you can build an oss modules as per

http://trisquel.info/en/wiki/install...s4-trisquel-40

but then also pls spare some time to read some of the excellent comments on debian matter here
http://forums.debian.net/viewtopic.php?p=304978

good luck

Many thanks for this tip. Kind regards,
Paul

blacklisting a module just means that it will not load at boot time.

using the options index=-2 means that it will not load "first" at boot time.

You can still modprobe and insmod modules manually regardless of those entries.

As far as the firmware module(s), modprobed modules will grab other modules when needed. This is normally done by the dependencies discovered by a depmod command generally run after a kernel is built and installed. In the case of alsa, these dependencies are not as simple, which is why you need a .conf in /etc/modprobe.d/ to tailor the dependencies for your specific card. When that .conf is correct, you can modprobe -r the module out of RAM and it takes down related modules. Or modprobe the module into RAM and it grabs all the related modules. When it is wrong you have to do each module manually in a specific order to use them. While said conf is not mandatory to use the modules, it is highly recommended. It's existence will autoload the modules when the mixer restores your levels at boot time.

It is possible to load the wrong driver. It is possible for said driver to interfere or override the correct driver. Which is most of the reason for blacklist and index=-2 modules in the distro supplied .conf files of that /etc/modprobe.d/ location. Normally when you grab the right module it will put some information in dmesg aka /var/log/dmesg. It's not always the case, but it's a common practice. Especially when firmware is involved and may have multiple versions of firmware to choose from (like wireless cards).

Information always good to know.

I do understand the message, but this is probably a bit above my competence.
Many thanks and kind regards,
Paul