Reputation: 1509

Latency issues with MIDI Over Bluetooth

I'm playing around with MIDI-Over-Bluetooth, but am getting latency issues between iOS devices, and also between iOS and OSX Yosemite. Haven't done any extensive testing on the desktop, but between devices there's around 34ms of latency, which is far too much for MIDI. Is anyone experiencing similar issues, and are there ways to make everything a bit more snappy?

The test simply sends a timestamp to another device, which then sends it back to the original device. Divide the difference between the current and transmitted timestamp values by 2, and you have a very rough score of latency.

Upvotes: 4

Answers (5)

Fabien Gaubert

Reputation: 38

I think some answers are confusing, so I will try to explain what I understand about BLE latency. Bluetooth devices don't communicate continuously. Once two devices are connected, they exchange data every "connection interval", which is one of the parameters defined at the start of the connection (between 7.5ms and 4 seconds from the Bluetooth specifications).

If the connection interval is 7.5ms, it doesn't mean that the transmission takes 7.5ms. It means that packages are sent every 7.5ms. Hence 7.5ms is the maximum time a data has to wait before being sent (if the data is small enough to be sent in one package). A latency of 7.5ms would only happen if a data is ready to be sent just after a Bluetooth connection occurred. In that case, that data would have to wait until the next connection.

We also need to add the time required by the drivers to transform the data to be sent into a Bluetooth package and send it through radio transmission.

What comes out of this:

latency is variable, a data will have to wait more or less depending on when was the last connection
BLE average latency would be close to ((connection interval)/2 + time that it takes for the information to go through the Bluetooth drivers of the transmitter and the receiver)

The connection interval can't be known with certainty and will depend on the central device.

Upvotes: 1

Rob Garner

Reputation: 1

I know this has been discussed a while ago, but I think there is still a lot of confusion out there regarding actual Bluetooth LE (Low Energy) timing, so I hope the following will help clarify this a little.

Bluetooth LE sends data packets in certain connection intervals. The smallest possible time interval is 7.5ms. In addition, depending on the version of Bluetooth LE your hardware is using, the maximum length of the data packet (payload) that can be sent during every transmission will also vary. For Bluetooth LE V4.0 the maximum payload length is 20 bytes. For the newer versions (4.2, 5.0) a packet length extension has been added, so now it is possible to send up to 250 bytes every 7.5ms. So, for hardware that uses V4.0 BLE (Bluetooth LE) you will need more than one connection interval if you need to send more than 20 bytes at a time. Assuming you need to send 30 bytes (which could easily be the case if, for example, you play 10 notes at the same time on a keyboard) it will take at least 13ms (2 x 7.5ms) to transmit the 30 bytes.

There is also an additional factor in play here. Most Smart devices will not allow the fastest connection interval of 7.5ms, because their software also has to deal with other parts of the system hardware. So quite often the lowest connection interval that they will allow is 30ms, which is quite noticeable in terms of latency. This is usually out of the users control, as the connection interval is negotiated between Bluetooth Low Energy devices at the Link layer level (deep down in the hardware, decided by the Bluetooth protocol). I am therefore not at all surprised that many users (such as Dennis George above) report latencies of around 30ms.

I am now writing this at the end of 2019, but basically the issue is still the same. Bluetooth Low Energy was never really designed for streaming large amounts of data. The recent packet length extension does help, but latency will always be an issue.

Upvotes: 0

Anonymous Coward

Reputation: 36

Was looking for info about MD-BT01 latency, didn't find any, but previous answers imply atleast 20 ms.

I came across a comment that someone had calculated the latency for real drum kit (no software) is ~2 ms. I'm horrid at math so I can't confirm that. However another source (dawbench*) that suggests there are interfaces that can do as low as 3 ms. Another source (androidaudiopathlatency) says that lowest latency measured from Ipad was 5 ms.

I think part of the problem is midi itself as well. Sure by writing the midi related firmware on both ends of the wire, you might be able to get the latency to nothing, but what about when there's ton of input or output? It's still a serial protocol. Sure, you might be able to hack around that by say, skewing the tempo momentarily and groove-quantizing the notes to clock etc - which I suppose is something that the couple high-reputation midi hw does (akai MPC does something like that, so if user input is bit off against running loop, it will fix the timing for next loop).

Point being, it's still quite a hack. If you were professional-level keyboard player and didn't want to sound like a drum machine groove but more like a jazz impressionist, I'm like... 99.99% sure you can't do that with midi. That's why Yamaha used to have another port that bypassed midi-encoding even in their entry-level $100 midi-keyboards. But that of course is only supported by DOS and Windows 98 sequencers.

Point being #2. To really record tight midi or anything, one needs a driver or mod to the OS that turns off various modern OS features, such that the computer could essentially turn into as accurate measurement device as say analog oscilloscope. OR... perhaps one could use soundcard as the 'oscilloscope' by making a hardware kit that converts serial-"midi" (yamaha) and regular midi, to audio, and then also use 2nd channel to record audio at same time. Then you have an audio-representation of the midi signals and actual audio (if you played say a synth that produced midi + audio but was concerned the midi signal might have latency or jitter that you had no control over as it might be due to the source you are using) - and then align those on the computer after recording.

edit: quote from "The Truth About Latency" "Although many musicians complain that MIDI is inherently flawed, since an eight-note chord will emerge as eight notes spread over 8ms, the reality is that it's almost impossible to hear this in a real-world situation."

That sort of sums it up once you know that 0.5 ms is definitely perceptible. I base this 0.5 ms to drum groove software that offers such tiny adjustments to the groove. It can be the difference between almost tight and tight drum groove. I only just now came across this quote. I wish I had known it back when I was trying to record midi and was super frustrated why it felt right when I input the notes live in realtime vs felt off when listening to the recorded midi (free running sequencers, no quantization).

edit 2:

Found illustration of the problem! http://www.spikenzielabs.com/SpikenzieLabs/Serial_MIDI.html Oscilloscope shot shows latency from midi note-on sent from microcontroller to computer audio output. 25 ms! This should be 2 ms to be equivalent to analog drums.

http://www.dawbench.com/audio-int-lowlatency3.htm

Upvotes: 1

Dodgyrabbit

Reputation: 3327

Is anyone experiencing similar issues

Yes, I have noticed the high latency with BLE MIDI.

My setup is a Yamaha Silent Piano which has a MIDI port. I use the MD-BT01 dongle which transmits MIDI signals via BLE to an iPad.

The total time between playing a note and hearing the sound (directly from iPad, not BT audio which will cause even more delay) is noticeable and distracting.

are there ways to make everything a bit more snappy?

I don't believe there is much you can do, since certain timing constraints are written into the BLE MIDI spec. My research yielded some links worth reading:

My conclusions:

BLE latency will be minimum 20ms or so. This is baked in the the spec and nothing you can do about it.
When you add on the application latency (i.e. time to process midi, produce polyphonic wave forms, output to speaker) you're probably in the > 50ms area.
For instruments like Piano, you'd need a USB or other wired connection.

Upvotes: 1

CL.

Reputation: 180010

According to the PR of some Bluetooth latency-optimized product,

[our cool product] offers a total end-to-end latency of just 32 milliseconds (ms) – far less than the standard Bluetooth latency of more than 150 ms (+/-50ms).

So if you get around 34 ms with your own code, that's as good as it gets.

Bluetooth just is not suitable for real-time MIDI.

Upvotes: -1

Latency issues with MIDI Over Bluetooth

Answers (5)

Related Questions