[alsa-devel] [RFC] MIDI over Bluetooth Low Energy

[Felipe Tonello]

Hi Marcel,

On Thu, Oct 1, 2015 at 12:16 PM, Marcel Holtmann <marcel at holtmann.org> wrote:
> Hi Felipe,
>
>>>> I am planning to start the support of MIDI BLE profile[1]. This
>>>> profile is not officially supported yet, but it will most likely be
>>>> very similar, so development efforts are still valid.
>>>>
>>>> I suggest two main goals:
>>>> * To be transparent to applications, i.e., use rawmidi and sequencer
>>>> ALSA interfaces to interact.
>>>> * To support peripheral and central BLE roles.
>>>>
>>>> My question is: what is the best way possible of doing it?
>>>>
>>>> My initial though is to write a GATT BlueZ profile plugin that will
>>>> load snd-virtmidi module with id and midi_devs parameters, then read
>>>> and write seq events from/to it. I am not sure if this is really
>>>> possible.
>>>
>>> If that doesn't involve creating new threads that would be the
>>> direction I would suggest.
>>
>> I don't think it will be necessary. Does bluetoothd run plugins as threads?
>>
>>>
>>>> Another way of implementing is as a rawmidi and a seq plugin using the
>>>> BlueZ GATT D-Bus interface. IMO this is not ideal because it requires
>>>> a lot more work (rawmidi and seq plugins, maybe even a library to
>>>> avoid code duplication) and has an overhead of using dbus.
>>>
>>> D-Bus is not meant for data, in fact GATT is not meant for byte stream
>>> either since the channel is shared with all other profiles it can
>>> cause delay.
>>
>> GATT can handle MIDI throughput very easily. Usually messages are 1 to
>> 10 Hz, 3 or 4 bytes each. Even SysEx messages tend to be 250 bytes at
>> maximum.
>>
>>>
>>>> It is also possible to write a kernel module to handle ALSA
>>>> card/device setup and reads and writes from the bluez plugin (perhaps
>>>> this simplifies things because it has less dependencies).
>>>
>>> Well if it uses the profile uses ATT/GATT then this is not possible
>>> since that is implemented in userspace, I guess creating virtual cards
>>> would be better (we do that for HoG using uhid), but I guess that is
>>> not currently possible otherwise we would have done that for A2DP/HFP
>>> already.
>>
>> The kernel module would act as a virtual card as well. The reads and
>> writes would come from user-space (because as you said, ATT/GATT is
>> implemented there). The good point is that it would be dedicated for
>> midi. It is like loading a usb midi gadget.
>
> I would prefer if you implement this completely in userspace. I do not think any extra new kernel module is needed. ALSA should easily support userspace MIDI cards.

AFAIK there is no way to create ALSA cards in userspace, unless you
load a kernel module that does it.

>
> Also I would think that first attempt should be implement this as D-Bus client utilizing our GATT API. That way it would be not introducing complex dependencies in BlueZ. Only if the timing is a problem, I would consider doing this as a plugin for bluetoothd.

Fair enough. The only limitation I see is no peripheral support via
D-Bus API, which is one of the requirements I see.

Felipe