ALSA can't find midi controller on BeagleBone Black

Hi!

I’ve been trying to solve this problem all day and now I’m all out of ideas. I have a BeagleBone Black rev C and I’m running SuperCollider on it for a live performance thing. The problem arises when I try to connect a midi controller to it (the Korg nanoKONTROL2). On my desktop computer (Ubuntu Studio) it works plug & play, but on the BBB SuperCollider can’t find it at all and SC gets its midi in/out from ALSA so it must be that ALSA can’t find it for some reason.

“lsusb” shows it and “cat /dev/midi1” gives me live output from it. It even shows up in “cat /proc/asound/cards”. The USB sound card on the same USB hub works like a charm.

lsmod gives me

Module Size Used by
snd_seq 46038 1
snd_seq_device 5895 1 snd_seq
g_ether 23958 0
libcomposite 15028 1 g_ether
snd_usb_audio 100405 3
snd_hwdep 4885 1 snd_usb_audio
snd_usbmidi_lib 15375 1 snd_usb_audio
omap_rng 4062 0
mt7601Usta 458758 0

which seems like it might be some module missing. Originally I used an old BBB debian version, but I have now upgraded with a fresh flash of the eMMC and recompiled jack2 and SuperCollider without any luck. What should I do?

Cheers,

Erik Natanael Gustafsson

Erik,
Let me preface this by saying that I feel your pain and I dont understand how to fix the problem. It might be something software related that someone will help us with or it might be a fundamental flaw in the BBB usb hardware. I am not sure. My below input is intended to help add some more light in the search for an answer…

I and other people have wasted several days troubleshooting the same thing that you are referring to. There is something wrong with the BBB USB handling that is maddening. Here are a few things I have discovered on the subject:

  1. The BBB has problems using my generic USB midi device (works 0% of the time), but the Raspberry Pi and Ubuntu Laptop can use it without problems (works 100% of the time).

  2. I have found that things do show up in both systems using the “lsusb” command…BUT for some reason something goes wrong during the USB enumeration process on the BBB. If you look at the output of “dmesg” you can see some strange descriptor errors that happen during the BBB enumeration process. As a result, when you do “aconnect -i” or “aconnect -o” or “aconnect -l” on the rPi you can see that the proper endpoints have been setup…but on the BBB that does not happen.

root@rPiB1:~# aconnect -i
client 0: ‘System’ [type=kernel]
0 'Timer ’
1 'Announce ’
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 20: ‘USB2.0-MIDI’ [type=kernel]
0 ‘USB2.0-MIDI MIDI 1’
client 128: ‘qlcplus’ [type=user]
0 'QLC
root@rPiB1:~# aconnect -o
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 20: ‘USB2.0-MIDI’ [type=kernel]
0 ‘USB2.0-MIDI MIDI 1’
1 ‘USB2.0-MIDI MIDI 2’
client 128: ‘qlcplus’ [type=user]
0 'QLC

On my Ubuntu laptop:
frenchy@frenchy-HP-2000-Notebook-PC:~$ aconnect -l
client 0: ‘System’ [type=kernel]
0 'Timer ’
1 'Announce ’
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 20: ‘USB2.0-MIDI’ [type=kernel]
0 ‘USB2.0-MIDI MIDI 1’
1 ‘USB2.0-MIDI MIDI 2’
client 128: ‘qlcplus’ [type=user]
0 'QLC

On the BBB:
I never grabbed the output for my notes (whoops), but the endpoints werent there.

Here are the notes that I wrote to myself a few days ago when I was researching this:
-Regarding the BBB, I think I wasted a whole day on the same problem about 1or2 years ago when it came to those cheap $4 Bluetooth adapters from China…the “lsusb” command saw the device (same as today with the USB midi device.)…but then dmesg started throwing strange descriptor errors during the 2nd phase of USB enumeration…as a result, the device is never really registered properly with the kernel level software modules like bluez in the bluetooth case or alsa’s aconnect in today’s case.

-What a freaking waste of time caused by the BBB for me and other people!!!

-Two years ago with the Bluetooth problem I deduced that it is caused by cheap chinese («««<$) devices which skimp on the Vbus bulk bypass capacitance. For whatever reason rPis and Laptops dont seem to have a problem!! But the BBB consistently crashes because of a Vbus dip during USB enumeration…the crash happens when the device is supposed to be sending some descriptors over…so it is never recognized properly…and therefore never fully functional nor available to the linux system. [Not sure if an unstable Vbus is really the problem…it was just a theory I was wondering about.]

Here is another guy who came to perhaps similar conclusions:
https://autostatic.com/2013/09/17/exit-beaglebone-black-hello-cubieboard2/

Good Luck and let me know if you find anything that leads to the USB midi device working on the BBB. I have not been able to get it working yet. Right now I have reached the sad conclusion that if I want to use my USB midi device, then I have to use the rPi instead of the BBB. Interestingly, I am able to use cheap USB soundcards (audio only) with the BBB all the time without problem (per my 7part tutorial here).

respect,
frenchy (Steve French)
www.voltvision.com

Erik,
Let me preface this by saying that I feel your pain and I dont understand how to fix the problem. It might be something software related that someone will help us with or it might be a fundamental flaw in the BBB usb hardware. I am not sure. My below input is intended to help add some more light in the search for an answer…

I and other people have wasted several days troubleshooting the same thing that you are referring to. There is something wrong with the BBB USB handling that is maddening. Here are a few things I have discovered on the subject:

  1. The BBB has problems using my generic USB midi device (works 0% of the time), but the Raspberry Pi and Ubuntu Laptop can use it without problems (works 100% of the time).

Can you try the 4.1 kernel?

  1. I have found that things do show up in both systems using the “lsusb” command…BUT for some reason something goes wrong during the USB enumeration process on the BBB. If you look at the output of “dmesg” you can see some strange descriptor errors that happen during the BBB enumeration process.

Can you share?

As a result, when you do “aconnect -i” or “aconnect -o” or “aconnect -l” on the rPi you can see that the proper endpoints have been setup…but on the BBB that does not happen.

root@rPiB1:~# aconnect -i
client 0: ‘System’ [type=kernel]
0 'Timer ’
1 'Announce ’
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 20: ‘USB2.0-MIDI’ [type=kernel]
0 ‘USB2.0-MIDI MIDI 1’
client 128: ‘qlcplus’ [type=user]
0 'QLC
root@rPiB1:~# aconnect -o
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 20: ‘USB2.0-MIDI’ [type=kernel]
0 ‘USB2.0-MIDI MIDI 1’
1 ‘USB2.0-MIDI MIDI 2’
client 128: ‘qlcplus’ [type=user]
0 'QLC

On my Ubuntu laptop:
frenchy@frenchy-HP-2000-Notebook-PC:~$ aconnect -l
client 0: ‘System’ [type=kernel]
0 'Timer ’
1 'Announce ’
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 20: ‘USB2.0-MIDI’ [type=kernel]
0 ‘USB2.0-MIDI MIDI 1’
1 ‘USB2.0-MIDI MIDI 2’
client 128: ‘qlcplus’ [type=user]
0 'QLC

On the BBB:
I never grabbed the output for my notes (whoops), but the endpoints werent there.

Here are the notes that I wrote to myself a few days ago when I was researching this:
-Regarding the BBB, I think I wasted a whole day on the same problem about 1or2 years ago when it came to those cheap $4 Bluetooth adapters from China…the “lsusb” command saw the device (same as today with the USB midi device.)…but then dmesg started throwing strange descriptor errors during the 2nd phase of USB enumeration…as a result, the device is never really registered properly with the kernel level software modules like bluez in the bluetooth case or alsa’s aconnect in today’s case.

-What a freaking waste of time caused by the BBB for me and other people!!!

The 3.8 kernel doesn’t use DMA. That usually isn’t an issue, but could be for some devices.

-Two years ago with the Bluetooth problem I deduced that it is caused by cheap chinese («««<$) devices which skimp on the Vbus bulk bypass capacitance. For whatever reason rPis and Laptops dont seem to have a problem!! But the BBB consistently crashes because of a Vbus dip during USB enumeration…the crash happens when the device is supposed to be sending some descriptors over…so it is never recognized properly…and therefore never fully functional nor available to the linux system. [Not sure if an unstable Vbus is really the problem…it was just a theory I was wondering about.]

Here is another guy who came to perhaps similar conclusions:
https://autostatic.com/2013/09/17/exit-beaglebone-black-hello-cubieboard2/

Let’s find a fix. If I can replicate, maybe some capacitance can be shown to fix the issue.

Erik,
To be thorough, I just went back and plugged the USB midi device into my BBB and got this:

[You can see the midi adapter in the list below]
debian@vBBB9-Office-Cl4:~$ lsusb
Bus 001 Device 002: ID 1a86:752d QinHeng Electronics CH345 MIDI adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[Below shows that the alsa endpoints were NOT created for the device, which is very different from the rPi situation in my previous response!]
debian@vBBB9-Office-Cl4:~$ sudo aconnect -i
client 0: ‘System’ [type=kernel]
0 'Timer ’
1 'Announce ’

[Notice the strange descriptor errors below…]
debian@vBBB9-Office-Cl4:~$ dmesg | grep usb
[ 0.147858] usbcore: registered new interface driver usbfs
[ 0.147956] usbcore: registered new interface driver hub
[ 0.148299] usbcore: registered new device driver usb
[ 1.028641] usbcore: registered new interface driver cdc_ether
[ 1.028726] usbcore: registered new interface driver rndis_host
[ 1.028895] usbcore: registered new interface driver cdc_ncm
[ 1.031189] usbcore: registered new interface driver cdc_acm
[ 1.031473] usbcore: registered new interface driver usb-storage
[ 1.031701] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[ 1.032076] musb-hdrc musb-hdrc.0.auto: pdev->id = 0
[ 1.032101] musb-hdrc musb-hdrc.0.auto: drivers/usb/musb/musb_dsps.c:480 dsps_musb_init: OK
[ 1.032138] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 1.032155] musb-hdrc: MHDRC RTL version 2.0
[ 1.032168] musb-hdrc: setup fifo_mode 4
[ 1.032192] musb-hdrc: 28/31 max ep, 16384/16384 memory
[ 1.032339] musb-hdrc musb-hdrc.0.auto: *** mode=3
[ 1.032357] musb-hdrc musb-hdrc.0.auto: *** power=250
[ 1.033058] musb-hdrc musb-hdrc.1.auto: pdev->id = 1
[ 1.033085] musb-hdrc musb-hdrc.1.auto: drivers/usb/musb/musb_dsps.c:480 dsps_musb_init: OK
[ 1.033119] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 1.033135] musb-hdrc: MHDRC RTL version 2.0
[ 1.033147] musb-hdrc: setup fifo_mode 4
[ 1.033248] musb-hdrc: 28/31 max ep, 16384/16384 memory
[ 1.033396] musb-hdrc musb-hdrc.1.auto: *** mode=1
[ 1.033415] musb-hdrc musb-hdrc.1.auto: *** power=250
[ 1.033432] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[ 1.033750] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
[ 1.033797] musb-hdrc musb-hdrc.1.auto: supports USB remote wakeup
[ 1.033895] usb usb1: default language 0x0409
[ 1.033949] usb usb1: udev 1, busnum 1, minor = 0
[ 1.033969] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.033988] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.034005] usb usb1: Product: MUSB HDRC host driver
[ 1.034022] usb usb1: Manufacturer: Linux 3.8.13-bone70 musb-hcd
[ 1.034038] usb usb1: SerialNumber: musb-hdrc.1.auto
[ 1.034690] usb usb1: usb_probe_device
[ 1.034715] usb usb1: configuration #1 chosen from 1 choice
[ 1.034778] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[ 1.034949] hub 1-0:1.0: usb_probe_interface
[ 1.034969] hub 1-0:1.0: usb_probe_interface - got id
[ 1.136944] usb usb1: bus auto-suspend, wakeup 1
[ 1.145404] usbcore: registered new interface driver usbhid
[ 1.145422] usbhid: USB HID core driver
[ 1.245144] usb usb1: usb wakeup-resume
[ 1.245189] usb usb1: usb auto-resume
[ 1.453267] usb 1-1: new full-speed USB device number 2 using musb-hdrc
[ 1.572342] usb 1-1: ep0 maxpacket = 8
[ 1.573188] usb 1-1: skipped 1 descriptor after interface
[ 1.573205] usb 1-1: skipped 7 descriptors after interface
[ 1.573216] usb 1-1: skipped 1 descriptor after endpoint
[ 1.573226] usb 1-1: skipped 1 descriptor after endpoint
[ 1.573316] usb 1-1: default language 0x0409
[ 1.573482] usb 1-1: udev 2, busnum 1, minor = 1
[ 1.573497] usb 1-1: New USB device found, idVendor=1a86, idProduct=752d
[ 1.573508] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 1.573517] usb 1-1: Product: USB2.0-MIDI
[ 1.573924] usb 1-1: usb_probe_device
[ 1.573941] usb 1-1: configuration #1 chosen from 1 choice
[ 1.574048] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[ 1.574303] usb 1-1: adding 1-1:1.1 (config #1, interface 1)
[ 3.772427] rtusb init rt2870 —>
[ 3.772585] usbcore: registered new interface driver rt2870
[ 9.394238] snd-usb-audio 1-1:1.0: usb_probe_interface
[ 9.394273] snd-usb-audio 1-1:1.0: usb_probe_interface - got id
[ 10.029579] usbcore: registered new interface driver snd-usb-audio
[ 11.088773] usb0: MAC 90:59:af:58:eb:d0
[ 11.088791] usb0: HOST MAC 90:59:af:58:eb:dc
[ 11.108282] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
[ 11.109291] musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 2
[ 11.109325] musb-hdrc musb-hdrc.0.auto: supports USB remote wakeup
[ 11.112544] usb usb2: default language 0x0409
[ 11.112586] usb usb2: udev 1, busnum 2, minor = 128
[ 11.112599] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 11.112610] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 11.112620] usb usb2: Product: MUSB HDRC host driver
[ 11.112629] usb usb2: Manufacturer: Linux 3.8.13-bone70 musb-hcd
[ 11.112639] usb usb2: SerialNumber: musb-hdrc.0.auto
[ 11.115740] usb usb2: usb_probe_device
[ 11.115763] usb usb2: configuration #1 chosen from 1 choice
[ 11.115817] usb usb2: adding 2-0:1.0 (config #1, interface 0)
[ 11.115942] hub 2-0:1.0: usb_probe_interface
[ 11.115954] hub 2-0:1.0: usb_probe_interface - got id
[ 11.217066] usb usb2: bus auto-suspend, wakeup 1
[ 14.943620] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready

I am thinking the above descriptor issues are somehow related to the fact that the midi doesnt work on the BBB and the endpoints are not showing up in the “aconnect -i” list. But why this problem when neither the rPi nor my Ubuntu laptop have the problem?

Still not sure if USB Vbus is a problem on the BBB, but I remember this thread from some time ago:
https://groups.google.com/forum/#!msg/beagleboard/tYYMzO2M4LQ/SpXZxewcCLoJ

Also, the BBB has long had a history of USB problems that I remember from a few years ago…this is one reference:
https://groups.google.com/forum/#!topic/beagleboard/nuyyVDhU6bw

good luck!
-frenchy (Steve French)
www.voltvision.com

Jason Kridner said: Can you try the 4.1 kernel?
Frenchy says: Sorry for the dumb question, but can I just upgrade this image or do I need to download a new image?
debian@vBBB9-Office-Cl4:~$ uname -a
Linux vBBB9-Office-Cl4 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l GNU/Linux

Is it as simple as this?:
$ cd /opt/scripts/tools/
$ git pull
$ ./update_kernel.sh

If new image, where should I download it from? Thx!

  1. I have found that things do show up in both systems using the “lsusb” command…BUT for some reason something goes wrong during the USB enumeration process on the BBB. If you look at the output of “dmesg” you can see some strange descriptor errors that happen during the BBB enumeration process.

Can you share?

Yep see the response I did a few minutes after you asked this. I didnt see this post while I was responding with my dmesg output.

Let’s find a fix. If I can replicate, maybe some capacitance can be shown to fix the issue.

I will be glad to test here. I hope we find a fix. Not sure if an unstable USB Vbus would cause this…it is interesting how lsusb always works, but the other things dont.

thx,
frenchy

Also, the BBB has long had a history of USB problems that I remember from a few years ago…this is one reference:
https://groups.google.com/forum/#!topic/beagleboard/nuyyVDhU6bw

Fast forward two years, and we have kernel 4.x, and much better USB support it seems.

SO, I do not know about the USB ALSA adapters, but a couple years ago I experimented with a few USB bluetooth adapters, and the conclusion I came to was that these cheap ( 1 buck 20 ea. ) bt adapters all use the same MAC address . . . and that’s where the problems stem from . . . but I’m also no expert in bluetooth adapters either. I can look into it again, with this new 4.1.x kernel I’m using, and in fact had already been considering it.

The major turn off for me was that I was unaware off any reasonably sized bluetooth stacks / set of utilities. WHen I experimented a couple years ago, I found I had to pull in ~200M or more of garbage just to get it to almost work.

Steve, what’s the output of

$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01

For you ? This is the major factor for apt-get installing

William,
For me I get this:
debian@vBBB9-Office-Cl4:/opt/scripts/tools$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01

Same image as mine, except perhaps you’re using the LXDE image ? You should be able to . . .

$ apt-get update

$ apt-cache search linux-image | grep 4.1

I’m personally using . . .
$ uname -a
Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015 armv7l GNU/Linux

Oh and right . . to be complete.

Once you find an image you want, just apt-get install , and then reboot. However, if you’re happy with your current image, and it is on eMMC, you may want to consider experimenting on and sdcard first. In fact, this is how I run all my own images ( when I’m not using NFS root, or whatever ). I actually still have angstrom with the original 3.8 kernel on it. Well on a Rev A5A I use.

Erik, Jason and all,
Yes, it looks like upgrading to the new kernel might have solved my problems!!

I did this:
sudo apt-get update
sudo apt-get install linux-image-4.1.12-bone16
[reboot!!]

debian@vBBB9-Office-Cl4:~$ uname -a
Linux vBBB9-Office-Cl4 4.1.12-bone16 #1 Wed Oct 28 07:32:53 UTC 2015 armv7l GNU/Linux
debian@vBBB9-Office-Cl4:~$ lsusb
Bus 001 Device 002: ID 1a86:752d QinHeng Electronics CH345 MIDI adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
debian@vBBB9-Office-Cl4:~$ aconnect -i
client 0: ‘System’ [type=kernel]
0 'Timer ’
1 'Announce ’
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 16: ‘USB2.0-MIDI’ [type=kernel]
0 ‘USB2.0-MIDI MIDI 1’

This looks much better!!! I will try to access the midi stuff from Python sometime next week.
Erik, let me know if this helps with your situation with SuperCollider.

PS-Mr. Hermans, why do you use an rt kernel?
talk soon and thanks!
-frenchy (Steve French)
www.voltvision.com

PS-Mr. Hermans, why do you use an rt kernel?
talk soon and thanks!
-frenchy (Steve French)
www.voltvision.com

It makes some things more deterministic, and I was writing some code that benefits from a lower latency kernel. It seemed to make a difference, but I have no hard numbers to substantiate that.