3

I am exploring midi performance on OS X

My test rig is a puredata patch that sends a note on on a midi interface, then measure the time it took to come back on another one.

I tried different hardware and software as the in/out interfaces :

  • bidule (software)
  • custom nodejs with node-midi
  • an irig usb-midi interface with a midi cable between in and out
  • custom software built with the c++ rtmidi library
  • os x built in IAC bus

I always get a 10 to 30ms delay for the round trip ( puredata MIDI OUT -> interface -> puredata MIDI IN ), so i guess there is between 5 and 15ms lost in the input and the same on the output.

I tried the same setup with abeton live instead of puredata and got the same result.

Does anyone witness the same kind of result, or better, have a workaround ?

||improve this question
  • If it did I'm pretty sure I would know, because 20 ms is a LOT. What was your Ableton Live setup, exactly? I use Live as a MIDI router all the time and again I feel like I would find 20 ms to be ridiculously annoying and impossible to play. What MIDI interface(s) is/are you using exactly? Have you tried/used USB MIDI controllers? – Todd Wilcox Apr 16 '16 at 17:00
  • Midi is always going to generate at least 10ms per device. It's serial & has no true through function, so it will always be a re-transmit - & that's with no additional processing involved. – Tetsujin Apr 16 '16 at 17:00
  • @ToddWilcox - my comment is re the interface itself. Internal routing these days I wouldn't expect any noticeable delay at all. [Though it's many years since I had to serial-chain midi keyboards, or actually deal with any midi output at all. These days I have one master keyboard, everything else is in software ;) – Tetsujin Apr 16 '16 at 17:03
  • 1
    @ToddWilcox my ableton setup was a clip with one note routed to the output and another recording channel as input. The hardware interface was an iconnect2. I got the same kind of result with apple's IAC as an interface and with PureData instead of ableton. That's really sad ... – Edwin Joassart Apr 20 '16 at 17:14
  • 1
    @ToddWilcox no audio, it was a pure midi setup to test midi latency alone – Edwin Joassart Apr 25 '16 at 12:00
4

To answer the first part, no, Macs do not inherently present any latency. CoreAudio is a rock solid, extremely low overhead and one of the main reasons people go for Macs for audio. I get < 2ms latency in Ableton with my Apogee Duet.

Your latency is most likely coming from the interface. There's probably some external editor with either a buffer size or a setting to the tune of "enable delay compensation".

I wouldn't use Node or anything that runs JavaScript for audio. Fine for web audio toys but interpreted languages are no bueno for anything seriously low latency.

||improve this answer
  • 1
    I have a sub-ms latency with node when using OSC instead of midi. I mean it's not a node issue, even when i switch my homemade node patch with ableton live i've got the same 20ms result. And it's looks like it's not an interface problem as i tried 3 differents interfaces (hardware and software) and still got the same result. This is why i suspect os x to be the problem. – Edwin Joassart Apr 29 '16 at 14:28
  • 1
    And to complement my answer. The idea with this node software is to make a quick prototype. And once validated rewrite the engine as C++, just keeping the frontend as a node-webkit app. ;) – Edwin Joassart Apr 12 '17 at 14:46
4

Eventually found the reason!

It actually was Ableton fault. We spoke with an Ableton engineer who explain that there's some black magic happening in the Midi stack of Live. It will delay some midi to match the audio latency of the system.

The 20ms added latency is tied to the audio buffer (and will increase if you increase the audio buffer)

That makes sense for Ableton Live but not so much for latency benchmarking.

Pure Data does something similar. There's a "Delay (ms)" parameter in the Audio settings. It will actually impact the MIDI latency (very misleading). TBH i don't know if it's affect also audio.

End of story, it was the probing software that was in fault, and not the software being tested nor the OS :)

||improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.