[arch-general] Kernel Module snd_seq_midi No Longer Inserted Automatically

[Troy Engel]

On Thu, Apr 9, 2015 at 7:28 PM, Steven Grace <sgrace at pobox.com> wrote:
>
> All I'm trying to find out is how to diagnose this module problem further. I
> know that module snd_seq_midi is part of the "linux" package but I don't
> know what process used to add the module automatically; was it the Linux
> kernel, or ALSA, or something else? I think the change is a regression and
> I'd like it to be fixed but I don't know what package is responsible and
> would like to know how to find out. Thanks.

In general - when the hardware scan is triggered on boot (second
phase, not initramfs) it probes your hardware and looks for modules
that deal with the device. The udev subsytem is basically a fancy
ruleset on the messagebus - it listens for events and performs actions
in /dev. (this is grossly oversimplified, just work with me here :) )
It's the 2.6+ successor to hotplug and devfs.

Your system should be booting and finding a sound card; this triggers
the subsystem "sound" to load, which in turn triggers udev; take a
look in /usr/lib/udev/rules.d/50-udev-default.rules and you'll find
this stanza:

  SUBSYSTEM=="sound", GROUP="audio", \
    OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"

A double-equals means compare, a single means assign (so it's not all
loose like bash, there is a strict interpretation) and as expected +=
means add to. So when sound is detected, the udev tree should create
two device nodes -- /dev/snd/seq and /dev/snd/timer with group
'audio'. Does this happen on your machine, are you getting
/dev/snd/seq created from a fresh boot?

If you are, then that means the problem feels like it's in the seq
subsystem[1] -- when that node is created the core module (snd-seq)
should load as it's hooked into it and "see" your midi sequencer out
of this new device node and do the needful; but if you're not getting
this device node created, then it feels like the sound system isn't
triggering in udev correctly. You could of course correct the failure
with a simple .conf file over in /etc/modprobe.d/ but you're clearly
interested in determining the actual root cause.

Hope this helps! I know little about the sound subsystem (I push play,
I get music :) ), but deal with udev for storage and network devices
quite a bit. You may find it valuable to read this article, IMHO it's
quite a good writeup:
http://www.linux.com/news/hardware/peripherals/180950-udev

-te

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/core/seq