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. 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. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
