Skip to content

bluez5: implement BLE MIDI support

P V requested to merge pvir/pipewire:bt-midi into master

BLE MIDI support. Client and server modes are implemented.

To use this, session manager changes are also needed: wireplumber!453 (merged)

Bluez also has an existing BLE MIDI implementation, which feeds data into ALSA sequencer. That is usable also in Pipewire, devices would appear under the MIDI bridge. Talking directly to the device we can make use of the timestamps it sends, apparently that is not so easily done with ALSA API, and the BlueZ plugin does not make use of them. The Bluez plugin does not implement the server mode.

The data we receive is proxied by Bluez through a socketpair, which introduces some extra latency. Measuring this, the mean extra latency was somewhere around 50 us, and peak value somewhere below 1 ms. This is much less than the Bluetooth packet reception jitter at Bluez end, so implementing this outside Bluez like here seems viable.

The DBus munging necessary seemed to require adding some higher-level framework for dealing with DBus ObjectManager. The code in bluez5-dbus.c in principle could also use it later ( battery manager was done here, can be separated out; this was mostly done just as a test case better separate).

On Fedora, the SELinux policy appears to forbid Bluez passing socket pairs via Dbus. This causes bluetoothd to be killed when the MIDI node starts. SELinux policy changes are needed: #2780 (comment 1620076) (maybe something more specific than that can be made). See https://github.com/fedora-selinux/selinux-policy/issues/1458

  • needs still better testing
  • would be interesting to know if the latency is OK for real use (there's a small difference to USB midi, but have no expertise on this...)

See #2780

Edited by P V

Merge request reports