RPI unsusable after aconnect [solved]


I recently got my dev kit and burned the latest image on my sd card, booted with a screen and keyboard + midi keyboard, followed the instructions in Run Elk on Boards section of the docks but every time I connect any of my midi keyboards with aconnect the Pi becomes unsusably slow (not completely frozen but at 1 keystroke each 40 secs). Also the midi keyboard doesn’t seem to be working but could had to do with the overflow.

I followed tips on this question Debugging audio and MIDI connections to Dev Kit in the forum, and sound is indeed working if I launch the arpeggiator, but none of the mda vst versions seem to be working with midi.

The sushi command seems to be fine, it appears to be connected to the midi settings and aconnect command.

I tried:

  • sushi -r -c ~/config_files/mda-vst3-configs/config_mda_synth.json & then aconnect 16 128
  • sushi -r -c ~/config_files/mda-vst2-configs/config_mda_synth.json & then aconnect 16 128

and both block the Pi after calling aconnect.

Also running sushi in debug mode or launching aseqdump didnt help since the computer becomes too busy after connecting anything.



The midi keyboard works with sushi -r -c ~/config_files/mda-vst3-configs/config_mda_synth.json & then aconnect 16 128 except as I mentioned the system seems to be in overflow so it takes about 30 seconds to react, sometimes it’s a bit faster, but it’s so slow that note-offs are not received properly so the notes keep playing.

Any tips? I’m searching similar issues with aconnect in the wild but I didn’t find anything yet.

Hi vectorsize. When you say the Pi is blocked, I interpret that to mean that some process is eating all the available cpu so that the system is unresponsive, or at least so sluggish to be practically unresponsive. I can’t a known issue with those symptoms of the top of my head so I would suggest trying to track down what is keeping the pi busy.

Could you, in terminal, first run: cat watch /proc/xenomai/sched/stat to see what the cpu load of the audio processing thread is, just to make sure that that is not the culprit. And then run htop to see if there is a user space process eating all the avalilable cpu.

If sushi (would show up as sushi_64) shows abnormally high cpu usage then I would suggest running sushi with the - -log-level=debug option and then looking at the log file in /tmp/sushi.log you could post it here if it’s not obvious what the problem is.

Thanks Gustav, I will try that, just upfront, launching sushi is not really an issue, the problem occurs when I use aconnect with my devices (both different versions of Arturia midi keyboards). Launching sushi works fine.

Hey Vectorsize. It seems that the problem may likely be with the USB controller of the RPi. We have experienced usb midi message dropouts when running in USB speed 2.

If you haven’t done already, change the raspberry pi USB speed to 1 using the elk_system_utils command to change it to 1. This should hopefully solve these issues.

Do note that running the RaspberryPi’s USB in USB Speed 1 can case normal usb kerboards(not MIDI) to not work. If thats the case, use an ssh connection to communicate to the board :slight_smile:



thanks a lot Gustav and @Sharan that (USB speed 1) did the trick! :ok_hand:

1 Like

Sorry my bad it is indeed elk_system_utils. I can edit the original post. :slight_smile:


Is there a way to disable USB speed 1 or boot into fallback without ssh? I saw the counter to 10 failed boot fallback. I used USB speed 1 and then couldn’t figure out how to swap it back to use keyboard, I guess the only way is to connect via Ethernet and then ssh in?

Eh, had to use Ethernet and ssh in. Enabled wifi so I don’t have to go though that again. Weird thing is that my keyboard works and midi works without it locking up like it did before in speed 2.

Hi @bitcrusher,

The other way would be to connect with a serial cable using a standard FTDI TTL-to-USB converter, following the instructions here:

You should be able to get one of them very cheap on web stores or local electronic shops if you don’t have one. It’s a pretty handy tool to have for any kind of embedded development, even with other boards.