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

[Luiz Augusto von Dentz]

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.

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

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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Luiz Augusto von Dentz