MIDI over Bluetooth Low Energy on Linux

Two months ago I made a request for comments on the linux-bluetooth and linux-alsa lists to propose the implementation of the MIDI over Bluetooth Low Energy profile on Linux using BlueZ and ALSA.

The main goals of the project are:

  1. To be transparent to applications, i.e., use ALSA Sequencer interface (ideally also use ALSA RawMidi too[1]);
  2. Support Peripheral and Central Bluetooth GAP roles.

[1] The problem with this is that it requires a kernel module to create a rawmidi device.

MMA is almost done with the actual MIDI over BLE spec. But since it is very close to Apple’s one, we can actually start implementing it.

On the mailing list, BlueZ developers suggested to implement it using the GATT D-Bus API to read and write the MIDI I/O characteristic for the sake of simplicity of initial version. Although this recommendation is valid, it will probably not fit the low latency requirements for this type of application.

That is why I already started the implementation as a native BlueZ plug-in (using the new shared api’s) instead. I’ve also sent two patches to fix a bug on that new API, which still requires some more work.

What I’ve Got So Far

I have a simple BlueZ profile plug-in that setups up an ALSA Sequencer client and port, reads the MIDI I/O characteristics notifications and writes the MIDI messages to the Sequencer port. I have tested the Seaboard RISE with a Linux synthesizer that supports ALSA Sequencer and it seems to work pretty fine.

This initial version still lacks timestamp support, write support and central role support.


I’ve noticed that the connection with the Seaboard RISE was very unstable. Every time the RISE would send high throughput messages, the connection would drop. Then I’ve noticed that the RISE doesn’t send the Connection Update Command to the host and then BlueZ would not update the connection state to be in a lower latency. But that doesn’t happen on a iOS and Mac OS system, but why?

To understand what was going on, I connected to an iThing device as a peripheral exporting the MIDI Service and dumped the Connection Update Command data. I noticed that the Mac OS forced the connection parameters (instead of listening to the peripheral to suggest it) as follows:

  • Minimum Connection Interval: 6
  • Maximum Connection Interval: 12
  • Connection Latency: 0
  • Supervision Timeout: 200

As BlueZ supports the setting up connection parameters, I just changed the info file and reconnected. That caused my connection to be much more stable, but still not perfect. Eventually the connection still drops. So, that is something I still need to figure out. Any suggestions on it will be helpful.

I want to finish the timestamp and write support before releasing it. The central role can be implemented after the release, since I think the most exciting feature right now is to support BLE MIDI devices.

If you are interested in contributing, send me an email, I can share what I have it so far.

  • Pingback: BlueZ fork on github for MIDI over BLE | Hacking Linux Thoughts()

  • Nghia Pham

    Hi, I am interested in getting this to work. I have a MIDI keyboard and want to connect it to my ipad via the RPI-USB-BLE method, but I am not sure how to go about it. I followed the BLUEZ installation to get it all installed, but I think I need to use your fork of BLUEZ instead of the original one is that correct?
    I appreciated it very much if you could make a step-by-step guide for a clean Raspbian install to have your RPI-USB-BLE working; please add this to your readme file in the github directory.
    Appreciate your work and sharing it here. Cheers.