Hi, i am new to this forum, i am an electronic engineering student and i want to share with the Audio community some interesting results i found while working on a project for my university which consisted in an implementation of a BLE-MIDI (Bluetooth Low Energy MIDI) Controller.

First I apologize in advance for my bad English.

In this post i will address MIDI latency and jitter introduced by BLE-MIDI.
Please take the results with a grain of salt as i could have done some errors, it would be even better if any of you are willing to replicate my measurements and confirm/disprove my findings. Especially if any of you has a commercial BLE-MIDI device and can test its latency that would be great!

Gear used:
-two identical Apple MacBook Pro 2015 Intel i5 1.6 Ghz with OS X Yosemite
10.10.5.
- iPad 3 iOS 9.3.2
- Ableton Live 9.6.2TLDR RESULTS;
It seems that currently the BLE-MIDI protocol isn't properly implemented on at least, the iPad 3 and the MacBook considered.
I have tested multiple music Apps on iPad and none worked properly, on the MacBook i have only tested Ableton Live. Signicant BLE-MIDI jitter in the order of 13.97ms was found when a Macbook Pro is used to send BLE-MIDI data to the iPad 3.
Moreover it has been determined that even when BLE-MIDI data is sent between two identical MacBooks the BLE-MIDI jitter is very high, in the order of 11.5ms.
This signicant MIDI jitter is in both cases slightly higher than the connection interval of the BLE link and is caused by the the fact that BLE-MIDI timestamps are either not used at all or not used properly, either by the central devices O.S. or the music soft-wares that runs on these central devices.
Please note that these results applies strictly to the gear i have used. Maybe new iOS and the new MacOS or the new versions of Live don't have this problem.

How measurements were performed & how BLE-MIDI works in short

Basically i implemented, among other things, a MIDI DIN to BLE-MIDI bridging device on a BLE board --> details and code is available in my GitHub rep at :https://github.com/popcornell/MIDIno

I then proceeded to measure the latency introduced by BLE-MIDI transmission to test if my device was working with acceptable latency.
I wrote a program to run on the board that sends a note On message every second through BLE-MIDI.
In that same program i instructed the board to set a pin high just prior the instruction that tells the board that a noteOn message has to be transmitted.
The board will then be BLE-MIDI connected with a BLE-MIDI capable device such for example a MacBook. The MacBook runs Ableton Live and will then generate a sound upon receiving a note On message.

Then i measured the total BLE-MIDI latency with an oscilloscope comparing the audio signal from the MacBook with the signal from the board.
I also estimated the audio output latency due to buffering introduced by the MacBook and ruled out this figure from my measurements.

I found a pretty awful result: the mean value for the latency introduced was 8.601 ms while the maximum value for the MIDI jitter introduced was 11.56 ms.
Such an high MIDI jitter figure is unacceptable for any serious music application.
The most logical explanation is that i have programmed wrong the board.

Well, here is the interesting part: i tested BLE-MIDI transmission between two MacBooks and found a similar result for the jitter.
Again i used Ableton Live to send a note On every second on the "sending" MacBook while the "receiving" MacBook was used in the same way as before. Latency Mean Value: 21.65 ms Maximum MIDI Jitter value measured: 11.79 ms a value which is very similar to what was found between board and MacBook.

To comprehend this result one must delve into the BLE-MIDI Specification and into the Bluetooth Low Energy protocol.

Here is the BLE-MIDI Specification: https://developer.apple.com/bluetoot...cification.pdf
Basically it requires that messages should have Timestamps to ensure proper synchronization and to minimize jitter.
Also it states that the minimum possible latency attainable with BLE-MIDI is equal to one connection interval and thus, as BLE protocol allow a minimum of 7.5 ms for a connection interval, 7.5 ms is the lowest latency currently attainable with BLE-MIDI.
The connection interval is, in short, the timeframe between data exchanges between two ble devices.

I also found that at least on iOS and OSX it is not possible to change the connection interval from the peripheral device (simply put the device that accepts the connection or makes the connection in BLE what is called the central device) dictates the connection interval.
I can set on the peripheral device some preferred connection parameters, i have tried this, no matter what i set as maximum acceptable connection interval the iOS device or OSX device imposes its own.

I found sniffing BLE traffic that when connected with the board: iPad 3 imposes a connection interval of 15 ms. Macbook 11.5 ms. This basically tells that for these devices these are the minimum possible latencies attainable with BLE-MIDI providing Timestamps are used correctly.

But what about the mean value of roughtly 8 ms i have measured with instantaneous minimum values of even 6 ms (which are less than the allowed theoretical minimum for BLE-MIDI)?

Short answer: Timestamps are not used or not interpreted correctly by the receiving device in this case the MacBook either by the O.S. or the software, in this case Ableton Live.

The correct interpretation of timestamps is of utmost importance in BLE-MIDI.
As Bluetooth Low Energy protocol exchanges data only in discrete event called connection events spaced by a connection interval, MIDI data is sent only in these very short timeframes. Timestamps contain information from the sender that tells the receiving device how these MIDI events should be spaced in time.
MIDI data is appended with a timestamp and it is queued till the next connection interval. Then ALL MIDI Data is sent. The receiving device must handle the timestamps and must space the MIDI events adding a delay when this MIDI data is recorded/played.

I have an image to illustrate this but gearslutz doesn't allow me to link images (cause i'm new).

To further test my theory i have made an additional measurement with the board: this time i will not send timestamps from the board at all, i will set for every note on the timestamp to zero.

Aside from a missed packet which resulted in re-transmission in the next connection event (one connection interval later in this case 11.5 ms later),
the result was the same.

Moreover i noted that upon different measurements if i graph the latencies the "pattern" i obtain each time can be different especially if i modify the frequency the board sends the noteOn messages or if i connect and disconnect the board.

I have also reproduced this effect between two MacBooks, the "latency pattern" varies if i connect and reconnect the devices or if i increase or decrease the frequency the note On messages are sent. It is important to note that only the pattern changes not the statistical values ( minimum maximum mean etcetera).
This effect again is due to the fact that timestamps are not used.
In fact latency depends on when connection is established or where the noteOn messages that have to be sent falls into a connection interval if timestamps are not used. Thus if i graph for example a measurement session one time i obtain a "sawtooth like" pattern and another time a different one.

To explain this more clearly i have to upload images.

I have also made other tests concerning also an iPad 3, again the results strongly suggest that even in this case timestamps are not used or used improperly.
I have tested the iPad 3 with several applications sending BLE-MIDI with my board or with a MacBook and the conclusions were all the same: unbearable MIDI jitter.

If you are interested i will post also my measurements for iPad 3 in detail.
Results are in TLDR section at the beginning for convenience.

Really interesting! I tried some quick tests myself. Between two macbooks I was getting ~26ms latency and jitter of up to 10.4ms. Not great when you consider that that doesn't include the applications' latency....