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

Steven Grace sgrace at pobox.com
Fri Apr 10 02:39:31 UTC 2015


On 04/09/2015 06:32 PM, Troy Engel wrote:
> 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

Thank you very much for this information. I confirmed that my 
50-udev-default.rules file contains the stanza you listed and that the 
two device nodes are being created.

If I'm understanding you correctly the Linux kernel is responsible for 
loading module snd_seq_midi and is apparently no longer doing that.

I didn't mention this previously but I'm not the only one experiencing 
this issue. I first posted at the LinuxMusicians forum and a user there 
who uses Arch had the same issue and used the same workaround of 
manually loading snd_seq_midi.


More information about the arch-general mailing list