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

[Luiz Augusto von Dentz]

Hi Felipe,

On Thu, Oct 1, 2015 at 1:17 PM, Felipe Tonello <eu at felipetonello.com> wrote:
> Hi Luiz,
>
> On Thu, Oct 1, 2015 at 10:34 AM, Luiz Augusto von Dentz
> <luiz.dentz at gmail.com> wrote:
>> Hi Felipe,
>>
>> On Thu, Oct 1, 2015 at 11:41 AM, Felipe Tonello <eu at 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.
>
> I don't think it will be necessary. Does bluetoothd run plugins as threads?

Nope, and most of the code in the daemon is no thread safe.

>>
>>> 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.

But the transport is shared between all services, you may have several
command in the queue and those can block the queue for up to 30
seconds before they timeout.
>
>>
>>> 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.

Well if you are proposing some module that would accept registering
virtual cards from userspace that probably would probably make sense,
this make it much simpler to be detected by the system as a regular
ALSA device so application can use.

>>
>>> 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.
>
> What is L2CAP CoC? I am not aware of it.

Connection oriented channel, I think it was introduced in Bluetooth
4.1, with that you can have a dedicated channel for your profile. This
is implemented in the kernel as a regular L2CAP socket btw.

>>
>>> Any ideas and comments?
>>>
>>> [1] https://developer.apple.com/bluetooth/Apple-Bluetooth-Low-Energy-MIDI-Specification.pdf
>>
>> It seems the specs is pretty old, from 2012, that probably explain why
>> L2CAP CoC was not used.
>
> I think that might be first draft, because it was released end of
> 2014. Also there are only two or three products out there implementing
> this protocol as it is new. I think will be a great thing if these and
> many other products runs as first class citizen in Linux too.
>
> BTW, is peripheral role fully supported on BlueZ? I did look into this
> beginning of 2014 and it was incomplete.

We do have advertising, GATT server and L2CAP CoC implemented, there
maybe a few details left though since some APIs are still
experimental.


-- 
Luiz Augusto von Dentz