Hi Marcel,
On Thu, Oct 1, 2015 at 12:16 PM, Marcel Holtmann marcel@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