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

[Luiz Augusto von Dentz]

Hi Felipe,

On Thu, Oct 1, 2015 at 3:04 PM, Felipe Tonello <eu at felipetonello.com> wrote:
> Hi Takashi,
>
> On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai <tiwai at 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 at 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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Luiz Augusto von Dentz