Poor MIDI Timing and Note Jitter in iOS

Published on Oct 12, 2012 by Kevin McCoy

"This really prevents iOS from being a serious platform for software instruments, despite its merits of having a touch interface and amazing sounding apps. Please comment if you have a solution!"

If anyone has a chance to look into this, feel free to comment or shoot me an email. Obvious things to consider are the app you are testing with, the MIDI interface being used, the iPad & OS versions, and any apps running in the background.

Update 1: discchord wrote in to let us know he ran a few tests. As I suspected it appears to depend on the setup and the device.

"Earlier iPhones were not nearly as beefy as iPads, so developers tried to support them as best they could with crazy high buffers that are easier on the CPU, but slower to react...

Considering how much of a mess my MIDI chain is, I think it is safe to say that a wired MIDI connection is reliable on iOS. Any faults come down to software that isn't designed to cope, or possibly an even worse MIDI setup than mine. Though I honestly can't imagine how that could be; I bought the Uno because it was the cheapest USB-MIDI interface I could buy locally!"

You can find the full results here. Be sure to see the previously linked post there for some initial tests as well.

Update 2: some notes on the results via David Lackey on this Facebook thread. It's worth noting David is the man behind Innerclock Systems and of course a bit of an expert behind timing and syncing gear.

"Again at the risk of sticking my neck in it - I just opened up that 240 BPM Wired 16th File [Quoted as 'There is slightly more wandering here, but still not enough that you'd notice. Take a listen for yourself.'] in Sound Forge and placed accurate markers on the events. At a perfect (no jitter) 240 BPM there should be exactly 3000 samples between each 16th audio event when recorded at 48kHz right. Here are the numbers:

2782/3358/2850/3286/2769/3335/2806/2774/3344 etc etc These variations amount to regular push-pull in tempo by more than 40 BPM PER EVENT in most cases I measured. I don't know about most people here but 40 BPM drift between 16ths is VERY NOTICABLE to my ears at any tempo.

....and I've just realized - those Discchord tests dont really tell you much about iOS Midi stability at all - take them with a large grain of salt - the 16th Midi Events they used are generated real-time by Live and USB Midi Interface - the Jitter probably has as much to do with the source events as the receiving iOS application.

You can see clearly that highly subjective and poorly researched statements like this: 'I hope this puts to rest the notion that MIDI Jitter prevents iOS from being a serious platform for software instruments.' need substantial qualification and backup before they can be taken seriously. For these tests to show true iOS application Midi Jitter we would need to see the jitter contained in the source Midi Events themselves first - or at least use a reliable hardware Midi Sequencer with proven event and tempo stability like an MPC-3000 as the Midi Event Source rather than DAW/USB/Driver generated Midi which is notoriously prone to slop and jitter anyway.

I'll run the same tests on Magellan/iPad2/iOS6 tonight but use MPC-3000/16ths as the Midi Event Source and post the results at 60/120 and 240 BPM."

See the Facebook thread in case any updates go up over time. 

Update 3: David Lackey of Innerclock ran some litmus tests. See this post for details.

Update 4: It looks like the iPad did fairly well with MIDI OUT depending on the app. Via David Lackey on the Facebook thread:

"Just had time last night to test outgoing Midi Event stability from two Apps - Magellan and Little Midi Machine - identical 16th note patterns using identical Roland UM-1G Core Midi Interface - you can see by the numbers that that Core Midi is certainly capable if the coding is up to the task. Little Midi Machine shows no more than 6 samples of jitter between 16th generated Note Events at 120 BPM. Magellan is still up there in the 500 plus samples jitter.

Details here: http://www.innerclocksystems.com/New%20ICS%20iLitmus.html"

Update 5 via Rob Fielding of Mugician, Geo Synth, & Cantor in the comments:

"This is probably not "MIDI" latency, but audio latency. The issue of iOS using oversized audio buffers is something that a minority of us iOS app devs (me especially) have been screaming about for years, especially just before Geo Synthesizer was released. Controller apps are crippled by this phenomenon at the moment, though the situation improved a lot last year. If the buffer is 512 at 44.1khz, then that's a 10ms buffer. If it's that large, then you will get jitter lower bound as a random variable from 0 to 10ms of latency no matter how fast everything else is. And in practice, there is always more overhead coming from elsewhere, including the hardware scanning for fingers to turn into touches, OS overhead, and MIDI packet sending, etc. I use 256 sized buffers (Mugician, Geo, Cantor), but I don't take MIDI in; so I experience this issue with almost all of the other iOS synths I run MIDI into. The apps that use a buffer size of 512 or higher are generally unplayable with Geo Synthesizer because you can play it so fast; you can really feel the difference between 512 (10ms) and 256 (5ms) buffers, though overhead makes total jitter almost 30ms. But the +/-10ms is enough to throw off rhythm.

and btw... iOS defaults to 1024 sized buffers but can usually go to 256 or 128 (good). Android on the other hand is a joke. Most Android apps have hundreds of seconds of latency (like 8192 buffers and even higher...yikes!) just due to audio buffer sizes, which means that hardware performance increases can never make a dent in the problem. Samsung Galaxy Nexus can get down to 512 I hear, which is almost to where it needs to be. It really needs to be 64, but 128 is doable for some synths, and no synths should settle for more than 256. I think AudioBus requires you to do 256. (But that's a whole new issue, because you are probably effectively chaining together audio buffer lengths when you pass from one app to another.)"