On Wed, 08 Apr 2015 17:09:36 -0700, Steven Grace wrote:

...

the wiki explains kernel modules here:

https://wiki.archlinux.org/index.php/Kernel_modules

I'd read the wiki page previously; it doesn't explain the details of what I'm looking for. It indicates that "Today, all necessary modules loading is handled automatically by udev..." but I haven't been able to find out *how* module loading is done by udev.

"Extra kernel modules to be loaded during boot are configured as a static list in files under /etc/modules-load.d/." $ ls -hAl /etc/modules-load.d/ total 0 Some modules should be part of /etc/mkinitcpio.conf. $ grep MOD /etc/mkinitcpio.conf | grep -v "#" MODULES="radeon" However to get the snd modules loaded there's nothing to do. $ zgrep SEQ /proc/config.gz CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_SEQ_HRTIMER_DEFAULT=y CONFIG_SND_RAWMIDI_SEQ=m CONFIG_SND_OPL3_LIB_SEQ=m # CONFIG_SND_OPL4_LIB_SEQ is not set # CONFIG_SND_SBAWE_SEQ is not set CONFIG_SND_EMU10K1_SEQ=m CONFIG_CRYPTO_SEQIV=m $ uname -r ; lsmod | grep snd_seq 3.10.61-rt65-1-rt-lts snd_seq_device 6545 1 snd_rawmidi snd 74970 12 snd_ice1712,snd_ac97_codec,snd_hdspm,snd_hwdep,snd_timer,snd_i2c,snd_pcm,snd_rawmidi,snd_ak4xxx_adda,snd_mpu401_uart,snd_seq_device,snd_cs8427 IOW the MIDI related modules are snd_seq_device snd_rawmidi snd_mpu401_uart there also isn't a module snd_seq_midi loaded on my MIDI and audio production machine. $ lsmod | grep snd_seq_midi $ Regards, Ralf PS: For what is the module needed? $ sudo modprobe snd_seq_midi $ lsmod | grep snd_seq_midi snd_seq_midi 5452 0 snd_seq_midi_event 7407 1 snd_seq_midi snd_seq 56506 2 snd_seq_midi_event,snd_seq_midi snd_rawmidi 22911 3 snd_hdspm,snd_mpu401_uart,snd_seq_midi snd_seq_device 6545 3 snd_seq,snd_rawmidi,snd_seq_midi

On 04/09/2015 12:20 AM, Ralf Mardorf wrote:

there also isn't a module snd_seq_midi loaded on my MIDI and audio production machine.

$ lsmod | grep snd_seq_midi $

Ralf, thank you for your response. On my Arch systems I have the same result as you for "lsmod | grep snd_seq"; snd_seq_midi is not listed. However, I'm convinced that snd_seq_midi *was* listed until sometime in March, and it's still listed on an Ubuntu-based installation running on the same machine.

For what is the module needed?

Without snd_seq_midi I don't have normal ALSA MIDI input, although I believe I still have some form of raw MIDI input. The output of "aconnect -i" doesn't list my MIDI devices until I manually add snd_seq_midi. Ralf, I know you're a musician, so if you use MIDI please feel free to verify this on your Arch system. With a MIDI input device connected (and powered on, if USB), I predict that "aconnect -i" won't list your MIDI device/interface. Add snd_seq_midi with modprobe, and "aconnect -i" should now list your MIDI device. I don't wish to bore the list with the specifics of how MIDI works in Linux. 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.

On 04/09/2015 06:32 PM, Troy Engel wrote:

On Thu, Apr 9, 2015 at 7:28 PM, Steven Grace 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/c...

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.

On Thu, 09 Apr 2015 20:01:38 -0700 Steven Grace wrote:

On 04/09/2015 07:39 PM, Steven Grace wrote:

Thanks to Troy for pointing me to package "linux" being the root of the problem. I found existing Arch bug #44286 for this issue; it's marked closed at the moment but others are requesting it to be re-opened (and rightly so, in my opinion).

I'm not looking for any further assistance; I'll monitor the bug page. Thanks.

I'll drop this in anyways :) I remember having a similar problem a year or two ago. I added snd_seq to /etc/modules-load.d/modules-load.conf to fix the problem. I hardly ever use midi so really don't know if it's still working, but lsmod | grep midi gives me the following (note that I'm booted into a 3.18-rt kernel and not the distro kernel): snd_seq_midi 13564 0 snd_seq_midi_event 14935 1 snd_seq_midi snd_rawmidi 30863 2 snd_hdsp,snd_seq_midi snd_seq 71606 3 snd_seq_midi_event,snd_seq_dummy,snd_seq_midi snd_seq_device 14497 4 snd_seq,snd_rawmidi,snd_seq_dummy,snd_seq_midi snd 87720 31 snd_hda_codec_realtek,snd_aloop,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_hdsp And aconnect -i: client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 20: 'Hammerfall DSP' [type=kernel] 0 'HDSP MIDI 1 ' Best of luck :) -- Joakim

On 04/10/2015 08:31 AM, Ralf Mardorf wrote:

With 3.10.61-rt65-1-rt-lts and my TerraTec and RME PCI/PCIe cards connected snd_seq_midi is missing, but it's not needed and all cards are shown by aconnect -i. If I connect an USB Korg nanoKONTROL and a swissonic USB MIDI IO, the USB drivers and snd_seq_midi get loaded. If I modprobe -r snd_seq_midi and disconnect and connect one USB device, snd_seq_midi gets loaded again. If I repeat it several time, then after a while snd_seq_midi doesn't get loaded anymore, but if I don't modprobe -r snd_usb_audio, then aconnect -i still lists all MIDI devices, including the USB devices, even without snd_seq_midi.

Now I see that you're using an older kernel -- the problem apparently started with kernel version 3.19. You're lucky you're not affected!

On 04/11/2015 01:17 AM, Ralf Mardorf wrote:

On Fri, 10 Apr 2015 17:21:03 -0700, Steven Grace wrote:

...

Now I see that you're using an older kernel -- the problem apparently started with kernel version 3.19. You're lucky you're not affected!

Hi,

this is what happens for

[rocketmouse@archlinux ~]$ pacman -Si linux | grep Ver; uname -rm Version : 3.19.3-3 3.19.3-3-ARCH x86_64

[1]

and

[rocketmouse@archlinux ~]$ uname -rm 3.18.9-rt5-2-rt x86_64

[2]

So there seemingly is a serious issue on my machine too, but it's not related to snd_seq_midi, since it's not needed, as you can see by [2] before the USB devices are connected.

Regards, Ralf

[1] Indeed, with and without USB devices connected aconnect -i doesn't see my MIDI devices, neither the PCI/PCIe, nor the USB devices.

Disconnected USB devices: [rocketmouse@archlinux ~]$ lsmod | grep midi snd_rawmidi 26806 2 snd_hdspm,snd_mpu401_uart snd_seq_device 13307 1 snd_rawmidi snd 73436 12 snd_ice1712,snd_ac97_codec,snd_hdspm,snd_hwdep,snd_timer,snd_i2c,snd_pcm,snd_rawmidi,snd_ak4xxx_adda,snd_mpu401_uart,snd_seq_device,snd_cs8427 [rocketmouse@archlinux ~]$ aconnect -i client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0'

After connecting USB devices: [rocketmouse@archlinux ~]$ lsmod | grep midi snd_usbmidi_lib 27571 1 snd_usb_audio snd_rawmidi 26806 3 snd_hdspm,snd_usbmidi_lib,snd_mpu401_uart snd_seq_device 13307 3 snd_seq,snd_rawmidi,snd_seq_dummy snd 73436 15 snd_ice1712,snd_usb_audio,snd_ac97_codec,snd_hdspm,snd_hwdep,snd_timer,snd_i2c,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_ak4xxx_adda,snd_mpu401_uart,snd_seq_device,snd_cs8427 usbcore 199382 9 uas,snd_usb_audio,usb_storage,ohci_hcd,ohci_pci,snd_usbmidi_lib,ehci_hcd,ehci_pci,usbhid [rocketmouse@archlinux ~]$ aconnect -i client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0'

[2] Disconnected USB devices: [rocketmouse@archlinux ~]$ lsmod | grep midi snd_rawmidi 30863 2 snd_hdspm,snd_mpu401_uart snd_seq_device 14497 1 snd_rawmidi snd 87720 12 snd_ice1712,snd_ac97_codec,snd_hdspm,snd_hwdep,snd_timer,snd_i2c,snd_pcm,snd_rawmidi,snd_ak4xxx_adda,snd_mpu401_uart,snd_seq_device,snd_cs8427 [rocketmouse@archlinux ~]$ aconnect -i client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 16: 'RME AIO_579bcc' [type=kernel] 0 'HDSPMx579bcc MIDI 1' client 20: 'TerraTec EWX24/96' [type=kernel] 0 'TerraTec EWX24/96 MIDI' client 24: 'TerraTec EWX24/96' [type=kernel] 0 'TerraTec EWX24/96 MIDI'

After connecting USB devices: [rocketmouse@archlinux ~]$ lsmod | grep midi snd_usbmidi_lib 30258 1 snd_usb_audio snd_seq_midi 13564 0 snd_seq_midi_event 14935 1 snd_seq_midi snd_seq 71606 3 snd_seq_midi_event,snd_seq_dummy,snd_seq_midi snd_rawmidi 30863 4 snd_hdspm,snd_usbmidi_lib,snd_mpu401_uart,snd_seq_midi snd_seq_device 14497 4 snd_seq,snd_rawmidi,snd_seq_dummy,snd_seq_midi snd 87720 15 snd_ice1712,snd_usb_audio,snd_ac97_codec,snd_hdspm,snd_hwdep,snd_timer,snd_i2c,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_ak4xxx_adda,snd_mpu401_uart,snd_seq_device,snd_cs8427 usbcore 243361 9 uas,snd_usb_audio,usb_storage,ohci_hcd,ohci_pci,snd_usbmidi_lib,ehci_hcd,ehci_pci,usbhid [rocketmouse@archlinux ~]$ aconnect -i client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 16: 'RME AIO_579bcc' [type=kernel] 0 'HDSPMx579bcc MIDI 1' client 20: 'TerraTec EWX24/96' [type=kernel] 0 'TerraTec EWX24/96 MIDI' client 24: 'TerraTec EWX24/96' [type=kernel] 0 'TerraTec EWX24/96 MIDI' client 28: 'USB Device 0x170b:0x11' [type=kernel] 0 'USB Device 0x170b:0x11 MIDI 1' client 32: 'nanoKONTROL' [type=kernel] 0 'nanoKONTROL MIDI 1'

Ralf, thanks for checking. The problem with snd_seq_midi no longer being automatically added appears to be a kernel issue. The Arch bug report has been re-opened: https://bugs.archlinux.org/task/44286 You indicate that snd_seq_midi is not important on your system. I'm guessing that perhaps you're using "raw" MIDI input instead of "seq". I have a workaround and will monitor the bug report for a permanent resolution. Thanks to all who responded.