Re: [arch-general] Kernel Module snd_seq_midi No Longer Inserted Automatically
On 04/08/2015 07:00 AM, arch-general-request@archlinux.org wrote:
Message: 3 Date: Tue, 07 Apr 2015 18:58:20 -0700 From: Steven Grace sgrace@pobox.com To: ML_arch-general arch-general@archlinux.org Subject: [arch-general] Kernel Module snd_seq_midi No Longer Inserted Automatically Message-ID: 55248B3C.3010103@pobox.com Content-Type: text/plain; charset=utf-8; format=flowed
I'd like help regarding a problem I'm having with kernel module snd_seq_midi. Until sometime in March this module was being automatically inserted; that's no longer happening. The module is still present and can be manually inserted with modprobe.
I know that snd_seq_midi is part of package "linux" but I don't know what's responsible for automatically inserting the module. I'd appreciate any information as to how I can find out.
The issue may have started with my update of linux to 3.19.2-1 on March 21. Today I updated linux to 3.19.3-1 but that didn't solve the problem.
It's also possible that the issue is related to ALSA; I updated alsa-lib and alsa-utils to 1.0.29-1 on March 10.
I'd appreciate any help regarding how snd_seq_midi used to be automatically inserted, or general information regarding how automatic module insertion works. Thanks.
Subject: Digest Footer
arch-general mailing list arch-general@archlinux.org https://lists.archlinux.org/listinfo/arch-general
End of arch-general Digest, Vol 126, Issue 7
the wiki explains kernel modules here:
https://wiki.archlinux.org/index.php/Kernel_modules
alternatively(though perhaps unecessary/ill-advised?) you could load the module early by adding it to mkinitcpio.conf and rebuilding your kernel. you can search "mkinitcpio, arch" for the arch wiki page on that.
good luck.
On 04/08/2015 10:16 AM, AIS Information wrote:
On 04/08/2015 07:00 AM, arch-general-request@archlinux.org wrote: I'd like help regarding a problem I'm having with kernel module snd_seq_midi. Until sometime in March this module was being automatically inserted; that's no longer happening. The module is still present and can be manually inserted with modprobe.
I know that snd_seq_midi is part of package "linux" but I don't know what's responsible for automatically inserting the module. I'd appreciate any information as to how I can find out.
The issue may have started with my update of linux to 3.19.2-1 on March 21. Today I updated linux to 3.19.3-1 but that didn't solve the problem.
It's also possible that the issue is related to ALSA; I updated alsa-lib and alsa-utils to 1.0.29-1 on March 10.
I'd appreciate any help regarding how snd_seq_midi used to be automatically inserted, or general information regarding how automatic module insertion works. Thanks.
the wiki explains kernel modules here:
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.
alternatively(though perhaps unecessary/ill-advised?) you could load the module early by adding it to mkinitcpio.conf and rebuilding your kernel. you can search "mkinitcpio, arch" for the arch wiki page on that.
I'd read that as well, but that's a last resort. I don't know why snd_seq_midi isn't loaded automatically anymore and so don't know if it's intentional or if it's a bug.
Thanks.
On Wed, 08 Apr 2015 17:09:36 -0700, Steven Grace wrote:
the wiki explains kernel modules here:
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
PPS:
On Thu, 9 Apr 2015 09:20:27 +0200, Ralf Mardorf wrote:
On Wed, 08 Apr 2015 17:09:36 -0700, Steven Grace wrote:
"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.
It likely loads the modules needed for the connected hardware. If you need additional modules:
"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/
If I connect a Korg nanoKONTROL additional sound modules get automatically loaded.
$ sudo modprobe -r snd_usb_audio [rocketmouse@archlinux ~]$ lsmod | grep snd_usb $
After connecting an USB MIDI device: $ lsmod | grep snd_usb snd_usb_audio 143298 0 snd_usbmidi_lib 20949 1 snd_usb_audio [snip]
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 Thu, Apr 9, 2015 at 7:28 PM, Steven Grace sgrace@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/c...
On 04/09/2015 06:32 PM, Troy Engel wrote:
On Thu, Apr 9, 2015 at 7:28 PM, Steven Grace sgrace@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/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 04/09/2015 07:39 PM, Steven Grace wrote:
On 04/09/2015 06:32 PM, Troy Engel wrote:
On Thu, Apr 9, 2015 at 7:28 PM, Steven Grace sgrace@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.
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.
On Thu, 09 Apr 2015 20:01:38 -0700 Steven Grace sgrace@pobox.com 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 :)
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.
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 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'
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.
Hi,
the problem described by https://lists.archlinux.org/pipermail/arch-general/2015-April/038789.html still appears with 4.0.1-1-ARCH.
I'm using Rt kernels, so I don't care about this kernel. I just want to inform that it still isn't fixed and at least it's an issue for the OP of the thread and it was for one engineer subscribed to Linux audio users.
After booting the kernel run aconnect or qjackctl. No MIDI devices are available.
$ aconnect -i client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0'
$ amidi -l Dir Device Name IO hw:0,0 HDSPMx579bcc MIDI 1 IO hw:1,0 TerraTec EWX24/96 MIDI IO hw:2,0 TerraTec EWX24/96 MIDI
$ sudo modprobe snd_seq_midi
$ 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'
FS#44812 - [Linux] MIDI devices don't show up with kernel 4.0.1-1-ARCH Attached to Project: Arch Linux Opened by Ralf Mardorf (Ralf) - Saturday, 02 May 2015, 11:44 GMT
https://bugs.archlinux.org/task/44812
Users of this kernel should consider to add comments and if needed to provide additional information, since I can't help much, because I'm usually running Rt kernels the whole day and I'm not willing to stop my work to reboot.
Regards, Ralf
participants (5)
-
AIS Information
-
Joakim Hernberg
-
Ralf Mardorf
-
Steven Grace
-
Troy Engel