Return-Path: MIME-Version: 1.0 In-Reply-To: References: <560D1893.6040509@ladisch.de> Date: Thu, 1 Oct 2015 15:46:47 +0100 Message-ID: Subject: Re: [alsa-devel] [RFC] MIDI over Bluetooth Low Energy From: Felipe Tonello To: Luiz Augusto von Dentz Cc: Takashi Iwai , Clemens Ladisch , "linux-bluetooth@vger.kernel.org" , alsa-devel@alsa-project.org Content-Type: text/plain; charset=UTF-8 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Luiz, On Thu, Oct 1, 2015 at 3:15 PM, Luiz Augusto von Dentz wrote: > Hi Felipe, > > On Thu, Oct 1, 2015 at 3:04 PM, Felipe Tonello wrote: >> Hi Takashi, >> >> On Thu, Oct 1, 2015 at 12:46 PM, Takashi Iwai 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 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