Hi Felipe,
On Thu, Oct 1, 2015 at 11:41 AM, Felipe Tonello eu@felipetonello.com wrote:
Hi guys,
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.
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.
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.
They all have the problem of context switching between bluez plugin and alsa midi driver. I would prefer to use a shared ring buffer between ALSA e BlueZ.
You can use anything you want but don't expose bluetoothd to attacks, so probably no shmem, actually if your concern is latency then as I said you shouldn't be using ATT/GATT, instead L2CAP CoC should be used but I don't think Apple has implemented it yet.
Any ideas and comments?
[1] https://developer.apple.com/bluetooth/Apple-Bluetooth-Low-Energy-MIDI-Specif...
It seems the specs is pretty old, from 2012, that probably explain why L2CAP CoC was not used.
PS: I am at #bluez and #alsa as ftonello.
Felipe Tonello
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html