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.
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.
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).
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.
Any ideas and comments?
[1] https://developer.apple.com/bluetooth/Apple-Bluetooth-Low-Energy-MIDI-Specification.pdf
PS: I am at #bluez and #alsa as ftonello.
Felipe Tonello
Hi Felipe,
>>> On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai <[email protected]> wrote:
>>>> On Thu, 01 Oct 2015 13:35:48 +0200,
>>>> Felipe Tonello wrote:
>>>>>
>>>>> Hi Clemens,
>>>>>
>>>>> On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch <[email protected]> wrote:
>>>>>> Felipe Tonello wrote:
>>>>>>> I am planning to start the support of MIDI BLE profile[1].
>>>>>>>
>>>>>>> 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?
>>>>>>
>>>>>> Just write a (user-space) sequencer client.
>>>>>
>>>>> But this will limit to seq interface only. It will not be available
>>>>> via rawmidi interface, right? Unless I load snd-virtmidi, correct?
>>>>
>>>> Right.
>>>>
>>>>> That was what I was suggesting at first, but I don't really like the
>>>>> idea of loading snd-virtmidi for that.
>>>>
>>>> Well, many audio/music apps may talk directly sequencer API, too, so
>>>> it's not too bad. Whether loading snd-virmidi is a system setup
>>>> question, and it'd be more or less static configuration like snd-seq
>>>> core module.
>>>>
>>>>>>> [...]
>>>>>>> They all have the problem of context switching between bluez plugin
>>>>>>> and alsa midi driver.
>>>>>>
>>>>>> Why would context switches be a problem?
>>>>>
>>>>> It is just too much travelling around. GATT messages are parsed in
>>>>> userspace by BlueZ, so it sounds unnecessary to copy buffers to the
>>>>> kernel and copy back to user space to the application (ALSA).
>>>>
>>>> Of course it'd be optimal if we can avoid context switching, but
>>>> usually its latency isn't too critical for MIDI, even on a much slower
>>>> machine in 20 years ago.
>>>>
>>>> So, IMO, we should go for a simpler implementation at first.
>>>
>>> Fair enough.
>>>
>>> So, initially the best way to go would be to write a seq back-end
>>> using D-Bus GATT API from BlueZ.
>>>
>>> An important thing to notice is that this implementation doesn't
>>> support BLE peripheral role.
>>
>> Did I give the impression you would not be able to implement
>> peripheral role? I did say that we do have advertising and GATT Server
>> support or perhaps that was not clear?
>
> Yes. You were clear. I said that because AFAIK the support only works
> as a bluetoothd plugin and not with the D-Bus API, right?
peripheral role is also supported over D-Bus.
Regards
Marcel
Hi Luiz,
On Thu, Oct 1, 2015 at 3:15 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Felipe,
>
> On Thu, Oct 1, 2015 at 3:04 PM, Felipe Tonello <[email protected]> wrote:
>> Hi Takashi,
>>
>> On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai <[email protected]> wrote:
>>> On Thu, 01 Oct 2015 13:35:48 +0200,
>>> Felipe Tonello wrote:
>>>>
>>>> Hi Clemens,
>>>>
>>>> On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch <[email protected]> wrote:
>>>> > Felipe Tonello wrote:
>>>> >> I am planning to start the support of MIDI BLE profile[1].
>>>> >>
>>>> >> 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?
>>>> >
>>>> > Just write a (user-space) sequencer client.
>>>>
>>>> But this will limit to seq interface only. It will not be available
>>>> via rawmidi interface, right? Unless I load snd-virtmidi, correct?
>>>
>>> Right.
>>>
>>>> That was what I was suggesting at first, but I don't really like the
>>>> idea of loading snd-virtmidi for that.
>>>
>>> Well, many audio/music apps may talk directly sequencer API, too, so
>>> it's not too bad. Whether loading snd-virmidi is a system setup
>>> question, and it'd be more or less static configuration like snd-seq
>>> core module.
>>>
>>>> >> [...]
>>>> >> They all have the problem of context switching between bluez plugin
>>>> >> and alsa midi driver.
>>>> >
>>>> > Why would context switches be a problem?
>>>>
>>>> It is just too much travelling around. GATT messages are parsed in
>>>> userspace by BlueZ, so it sounds unnecessary to copy buffers to the
>>>> kernel and copy back to user space to the application (ALSA).
>>>
>>> Of course it'd be optimal if we can avoid context switching, but
>>> usually its latency isn't too critical for MIDI, even on a much slower
>>> machine in 20 years ago.
>>>
>>> So, IMO, we should go for a simpler implementation at first.
>>
>> Fair enough.
>>
>> So, initially the best way to go would be to write a seq back-end
>> using D-Bus GATT API from BlueZ.
>>
>> An important thing to notice is that this implementation doesn't
>> support BLE peripheral role.
>
> Did I give the impression you would not be able to implement
> peripheral role? I did say that we do have advertising and GATT Server
> support or perhaps that was not clear?
Yes. You were clear. I said that because AFAIK the support only works
as a bluetoothd plugin and not with the D-Bus API, right?
Felipe
Hi Felipe,
On Thu, Oct 1, 2015 at 3:04 PM, Felipe Tonello <[email protected]> wrote:
> Hi Takashi,
>
> On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai <[email protected]> wrote:
>> On Thu, 01 Oct 2015 13:35:48 +0200,
>> Felipe Tonello wrote:
>>>
>>> Hi Clemens,
>>>
>>> On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch <[email protected]> wrote:
>>> > Felipe Tonello wrote:
>>> >> I am planning to start the support of MIDI BLE profile[1].
>>> >>
>>> >> 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?
>>> >
>>> > Just write a (user-space) sequencer client.
>>>
>>> But this will limit to seq interface only. It will not be available
>>> via rawmidi interface, right? Unless I load snd-virtmidi, correct?
>>
>> Right.
>>
>>> That was what I was suggesting at first, but I don't really like the
>>> idea of loading snd-virtmidi for that.
>>
>> Well, many audio/music apps may talk directly sequencer API, too, so
>> it's not too bad. Whether loading snd-virmidi is a system setup
>> question, and it'd be more or less static configuration like snd-seq
>> core module.
>>
>>> >> [...]
>>> >> They all have the problem of context switching between bluez plugin
>>> >> and alsa midi driver.
>>> >
>>> > Why would context switches be a problem?
>>>
>>> It is just too much travelling around. GATT messages are parsed in
>>> userspace by BlueZ, so it sounds unnecessary to copy buffers to the
>>> kernel and copy back to user space to the application (ALSA).
>>
>> Of course it'd be optimal if we can avoid context switching, but
>> usually its latency isn't too critical for MIDI, even on a much slower
>> machine in 20 years ago.
>>
>> So, IMO, we should go for a simpler implementation at first.
>
> Fair enough.
>
> So, initially the best way to go would be to write a seq back-end
> using D-Bus GATT API from BlueZ.
>
> An important thing to notice is that this implementation doesn't
> support BLE peripheral role.
Did I give the impression you would not be able to implement
peripheral role? I did say that we do have advertising and GATT Server
support or perhaps that was not clear?
> Felipe
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
Hi Takashi,
On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai <[email protected]> wrote:
> On Thu, 01 Oct 2015 13:35:48 +0200,
> Felipe Tonello wrote:
>>
>> Hi Clemens,
>>
>> On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch <[email protected]> wrote:
>> > Felipe Tonello wrote:
>> >> I am planning to start the support of MIDI BLE profile[1].
>> >>
>> >> 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?
>> >
>> > Just write a (user-space) sequencer client.
>>
>> But this will limit to seq interface only. It will not be available
>> via rawmidi interface, right? Unless I load snd-virtmidi, correct?
>
> Right.
>
>> That was what I was suggesting at first, but I don't really like the
>> idea of loading snd-virtmidi for that.
>
> Well, many audio/music apps may talk directly sequencer API, too, so
> it's not too bad. Whether loading snd-virmidi is a system setup
> question, and it'd be more or less static configuration like snd-seq
> core module.
>
>> >> [...]
>> >> They all have the problem of context switching between bluez plugin
>> >> and alsa midi driver.
>> >
>> > Why would context switches be a problem?
>>
>> It is just too much travelling around. GATT messages are parsed in
>> userspace by BlueZ, so it sounds unnecessary to copy buffers to the
>> kernel and copy back to user space to the application (ALSA).
>
> Of course it'd be optimal if we can avoid context switching, but
> usually its latency isn't too critical for MIDI, even on a much slower
> machine in 20 years ago.
>
> So, IMO, we should go for a simpler implementation at first.
Fair enough.
So, initially the best way to go would be to write a seq back-end
using D-Bus GATT API from BlueZ.
An important thing to notice is that this implementation doesn't
support BLE peripheral role.
Felipe
Hi Clemens,
On Thu, Oct 1, 2015 at 12:53 PM, Clemens Ladisch <[email protected]> wrote:
> Felipe Tonello wrote:
>> On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch <[email protected]> wrote:
>>> Felipe Tonello wrote:
>>>> I am planning to start the support of MIDI BLE profile[1].
>>>>
>>>> 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?
>>>
>>> Just write a (user-space) sequencer client.
>>
>> But this will limit to seq interface only. It will not be available
>> via rawmidi interface, right?
>
> Yes. And why would this be a problem?
None besides the obvious fact that rawmidi interface will be out.
>
>>>> They all have the problem of context switching between bluez plugin
>>>> and alsa midi driver.
>>>
>>> Why would context switches be a problem?
>>
>> It is just too much travelling around.
>
> It hasn't been a problem with any other MIDI application.
It can be for MIDI Multidimensional Polyphonic Expression (MPE)[1] .
[1] https://docs.google.com/document/d/1-26r0pVtVBrZHM6VGA05hpF-ij5xT6aaXY9BfDzyTx8/edit
Felipe
Felipe Tonello wrote:
> On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch <[email protected]> wrote:
>> Felipe Tonello wrote:
>>> I am planning to start the support of MIDI BLE profile[1].
>>>
>>> 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?
>>
>> Just write a (user-space) sequencer client.
>
> But this will limit to seq interface only. It will not be available
> via rawmidi interface, right?
Yes. And why would this be a problem?
>>> They all have the problem of context switching between bluez plugin
>>> and alsa midi driver.
>>
>> Why would context switches be a problem?
>
> It is just too much travelling around.
It hasn't been a problem with any other MIDI application.
Regards,
Clemens
On Thu, 01 Oct 2015 13:35:48 +0200,
Felipe Tonello wrote:
>
> Hi Clemens,
>
> On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch <[email protected]> wrote:
> > Felipe Tonello wrote:
> >> I am planning to start the support of MIDI BLE profile[1].
> >>
> >> 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?
> >
> > Just write a (user-space) sequencer client.
>
> But this will limit to seq interface only. It will not be available
> via rawmidi interface, right? Unless I load snd-virtmidi, correct?
Right.
> That was what I was suggesting at first, but I don't really like the
> idea of loading snd-virtmidi for that.
Well, many audio/music apps may talk directly sequencer API, too, so
it's not too bad. Whether loading snd-virmidi is a system setup
question, and it'd be more or less static configuration like snd-seq
core module.
> >> [...]
> >> They all have the problem of context switching between bluez plugin
> >> and alsa midi driver.
> >
> > Why would context switches be a problem?
>
> It is just too much travelling around. GATT messages are parsed in
> userspace by BlueZ, so it sounds unnecessary to copy buffers to the
> kernel and copy back to user space to the application (ALSA).
Of course it'd be optimal if we can avoid context switching, but
usually its latency isn't too critical for MIDI, even on a much slower
machine in 20 years ago.
So, IMO, we should go for a simpler implementation at first.
thanks,
Takashi
Hi Clemens,
On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch <[email protected]> wrote:
> Felipe Tonello wrote:
>> I am planning to start the support of MIDI BLE profile[1].
>>
>> 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?
>
> Just write a (user-space) sequencer client.
But this will limit to seq interface only. It will not be available
via rawmidi interface, right? Unless I load snd-virtmidi, correct?
That was what I was suggesting at first, but I don't really like the
idea of loading snd-virtmidi for that.
>
>> [...]
>> They all have the problem of context switching between bluez plugin
>> and alsa midi driver.
>
> Why would context switches be a problem?
It is just too much travelling around. GATT messages are parsed in
userspace by BlueZ, so it sounds unnecessary to copy buffers to the
kernel and copy back to user space to the application (ALSA).
Felipe
Felipe Tonello wrote:
> I am planning to start the support of MIDI BLE profile[1].
>
> 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?
Just write a (user-space) sequencer client.
> [...]
> They all have the problem of context switching between bluez plugin
> and alsa midi driver.
Why would context switches be a problem?
Regards,
Clemens
Hi Marcel,
On Thu, Oct 1, 2015 at 12:16 PM, Marcel Holtmann <[email protected]> wrot=
e:
> 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 threa=
ds?
>>
>>>
>>>> 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 th=
ink any extra new kernel module is needed. ALSA should easily support users=
pace 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 c=
lient 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 do=
ing 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
Hi Luiz,
On Thu, Oct 1, 2015 at 12:05 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Felipe,
>
> On Thu, Oct 1, 2015 at 1:17 PM, Felipe Tonello <[email protected]> wrote:
>> Hi Luiz,
>>
>> On Thu, Oct 1, 2015 at 10:34 AM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> Hi Felipe,
>>>
>>> On Thu, Oct 1, 2015 at 11:41 AM, Felipe Tonello <[email protected]> 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.
Hmm. I see. That can really be an issue. Is that BlueZ specific? Can
be worked out?
>>
>>>
>>>> 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.
Yes. As I see, this is the best option to have correct ALSA rawmidi
and seq interfaces support.
>
>>>
>>>> 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.
>
Felipe
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
Hi Felipe,
On Thu, Oct 1, 2015 at 1:17 PM, Felipe Tonello <[email protected]> wrote:
> Hi Luiz,
>
> On Thu, Oct 1, 2015 at 10:34 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Felipe,
>>
>> On Thu, Oct 1, 2015 at 11:41 AM, Felipe Tonello <[email protected]> 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
Hi Luiz,
On Thu, Oct 1, 2015 at 10:34 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Felipe,
>
> On Thu, Oct 1, 2015 at 11:41 AM, Felipe Tonello <[email protected]> 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?
>
>> 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.
>
>> 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.
>
>> 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.
Felipe
Hi Felipe,
On Thu, Oct 1, 2015 at 11:41 AM, Felipe Tonello <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz