Hi Luiz, On Thu, Oct 1, 2015 at 3:15 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Felipe, > > On Thu, Oct 1, 2015 at 3:04 PM, Felipe Tonello <eu@xxxxxxxxxxxxxxxxx> wrote: >> Hi Takashi, >> >> On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
