Pure Data, Android audio, and random stuff

Noisepages: Websites for smart artists.

A 2005 paper on MIDI over Bluetooth by Bartolomeu et al. presents some rather discouraging latency measurements. They report typical delays ranging from 25ms to 275ms, with the odd peak over 500ms, for events sent from the slave device to the master. For events sent from master to slave, the numbers are a little better but still bad, with typical delays between 15ms and 80ms. That’s very bad news, huge latency and terrible jitter, with a side of asymmetry. Their results seem sound, and their experimental setup indicates that they were really measuring Bluetooth delays and nothing else.

On the other hand, my initial experiences with my own MIDI over Bluetooth setup have been rather promising. I never noticed any major latency, but then again, I haven’t yet used it much, either. Time to investigate.

Since this project is strictly a hobby and I don’t intend to publish the results in any formal way, I figured that crude measurements with a certain systematic error would be acceptable. Here’s the basic setup: Take one MIDI cable and plug one end into the MIDI In port of the Bluetooth adapter and the other one into the MIDI Out port. Now send a MIDI event from the Android phone to the interface and measure the time until the phone gets the event back from the interface.

This approach has all sorts of problems, of course. It only measures round-trip times rather than one way, it relies on the timing capabilities of Java/Dalvik, and it is subject to the whim of the scheduler on the Android side. In other words, it measures a sequence of random delays, and the Bluetooth delays may only be a small part of it. Still, the results show that my initial impression was correct: I’m getting round-trip times between 30ms and 70ms, with a mean of 34ms and a standard deviation of 6ms.

In other words, the round-trip delays plus delays from other sources are much better than the one-way times that the 2005 paper reports. Those numbers are still not great; they probably won’t be good enough for highly sensitive musical applications. Still, they’re small enough to be useful in a lot of settings. I’m wondering where the improvement came from. My best guess is that technology has progressed since 2005; in particular, the BlueSMiRF modem that I’m using is a Bluetooth 2.1 device, while the authors of the paper were using Bluetooth 1.1. In any case, I’m glad I started hacking before I read their paper.


3 Responses

  1. [...] I convinced myself that MIDI over Bluetooth is viable, the breadboard approach didn’t seem adequate anymore, and so I fired up ye olde soldering [...]

  2. [...] and preliminary measurements of latency and jitter suggest that it performs about as well as the original version. I’ve since been told by a real electrical engineer that there’s a much simpler way to [...]

  3. [...] In part 2, he describes latency and jitter. Here’s what I’ve been told by mobile engineers to whom I talked: performance has greatly improved in Bluetooth implementations in recent years. That means that part of the reason Bluetooth MIDI may have been adapted is that, when people first began testing this a few years ago, the implementations weren’t yet good enough – and no one has checked since. (Until now, that is.) [...]

Leave a Reply