[alsa-devel] [RFC] MIDI over Bluetooth Low Energy
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-Specif...
PS: I am at #bluez and #alsa as ftonello.
Felipe Tonello
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
Hi Luiz,
On Thu, Oct 1, 2015 at 10:34 AM, Luiz Augusto von Dentz luiz.dentz@gmail.com wrote:
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.
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-Specif...
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 1:17 PM, Felipe Tonello eu@felipetonello.com wrote:
Hi Luiz,
On Thu, Oct 1, 2015 at 10:34 AM, Luiz Augusto von Dentz luiz.dentz@gmail.com wrote:
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.
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-Specif...
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.
Hi Luiz,
On Thu, Oct 1, 2015 at 12:05 PM, Luiz Augusto von Dentz luiz.dentz@gmail.com wrote:
Hi Felipe,
On Thu, Oct 1, 2015 at 1:17 PM, Felipe Tonello eu@felipetonello.com wrote:
Hi Luiz,
On Thu, Oct 1, 2015 at 10:34 AM, Luiz Augusto von Dentz luiz.dentz@gmail.com wrote:
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.
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-Specif...
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 Marcel,
On Thu, Oct 1, 2015 at 12:16 PM, Marcel Holtmann marcel@holtmann.org wrote:
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.
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 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.
Fair enough. The only limitation I see is no peripheral support via D-Bus API, which is one of the requirements I see.
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 Clemens,
On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch clemens@ladisch.de 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
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 clemens@ladisch.de 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 Takashi,
On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai tiwai@suse.de 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 clemens@ladisch.de 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 Felipe,
On Thu, Oct 1, 2015 at 3:04 PM, Felipe Tonello eu@felipetonello.com wrote:
Hi Takashi,
On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai tiwai@suse.de 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 clemens@ladisch.de 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Luiz,
On Thu, Oct 1, 2015 at 3:15 PM, Luiz Augusto von Dentz luiz.dentz@gmail.com wrote:
Hi Felipe,
On Thu, Oct 1, 2015 at 3:04 PM, Felipe Tonello eu@felipetonello.com wrote:
Hi Takashi,
On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai tiwai@suse.de 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 clemens@ladisch.de 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 12:46 PM, Takashi Iwai tiwai@suse.de 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 clemens@ladisch.de 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
Felipe Tonello wrote:
On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch clemens@ladisch.de 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
Hi Clemens,
On Thu, Oct 1, 2015 at 12:53 PM, Clemens Ladisch clemens@ladisch.de wrote:
Felipe Tonello wrote:
On Thu, Oct 1, 2015 at 12:27 PM, Clemens Ladisch clemens@ladisch.de 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-ij5xT6aaXY9BfDzy...
Felipe
participants (5)
-
Clemens Ladisch -
Felipe Tonello -
Luiz Augusto von Dentz -
Marcel Holtmann -
Takashi Iwai