Midi over network - performance?

Is anyone using midi over WiFi for expressive controllers - any issues with jitter/latency when you have large amounts of data caused by these controllers.

( I’m thinking using an access point on computer rather than WiFi router).

I’ve done some tests and appeared to be ok, but probably I’d need to do it for a while to see any gremlins.

Another option might be to use wired Ethernet but that’s not quite as ‘handy’…

im currently looking at things like rtp midi support, and also potentially hardware solutions…

rtpmidi - looking at what the current state is for standard Linux support is, or if you always have to install additional software.

BomeBox is ‘out’ , unfortunately it does not support Linux, and is also not rtpmidi compliant.

cinara have an interesting device, which seems to be rtpmidi router… basically midi din/usb -> rtpmidi
seems particular useful to bridge things

rtpmidi will work over wifi or ethernet, so im guessing i’ll just try rtpmidi and then use what is appropriate.’

found out iconnectivity have just released the mioXm, which looks like it could solve a number of my current midi routing requirements :slight_smile:

multiple usb device ports , one usb host port… and rtpmidi (only one port but use a network switch for multiple clients), and a few midi dins…

1 Like

From my experience with wifi as long as you keep it “loaded” latency and jitter are not a great problem, let it idle and it all goes to crap. I would say idle would be in the 40-100ms range, so constant comms keeps it all sweet.

Ethernet will always win though, gigabit ethernet has pretty low latency and jitter.

Edit: WIFI is of course susceptible to other WIFI devices using the same frequency where ethernet isn’t.

1 Like

I think only iConnectivity checks all “boxes” you mention…
I myself should update this type-of-box, and give them (iConnectivity) another chance :wink:
although I still have and use the smaller iConnectMidi2+ (with some quirks)

I leave some other ideas that cross my mind


1 Like

ok, so ive been doing some tests… to see if this is viable :slight_smile:


Ive a raspberry PI, which is running MEC to have the eigenharp connected to it, it is sending MPE MIDI.
Ive then connected this to my iMac which is running Equator or GigPerformer w/Aalto.

routing rtp midi on a rPI

I tried using raveloxmidi for rtpmidi -> mac , but it seems unstable - Ive logged an issue with developer, but not heard back yet :frowning:

so, I moved onto rtpmidi by McLarenLabs, this costs $5 and is not open source, but at least worked … however Ive also had a couple of issues with it, again contacted the developer to see if we can resolve.
whilst its not 100% reliable, it has allowed me to proceed with my tests.

observations/results of tests:

rtpmidi over wifi: as @BobTheDog said, wifi does seem to be fine … has a bit of latency (3-5mS?) , but its ok. I’d probably use it for convenience.

rtpmidi over ethernet: definitively better (1-2mS?) , so this is probably how Id go for a ‘proper setup’

I can’t really quote latency above properly, because while macOS does report it, Ive noticed its unreliable. I noticed that after playing for a while, latency would creep up n’ up, at one point showing 25ms, which was obviously not true (as I felt no lag) … my assumption is that over time the clocks drift apart.

rtpmidi on rPI is usually ok, but Ive had some issues with it crashing, it helped to turn off journalling , but it still had issues occasionally - useable, but probably annoying when used headless. it seemed pretty stable for low volume data.

rtpmidi on mac, as i said latency numbers are off, also I noticed if the client crashes you can appear to be able to lock up the midi subsystem on macOS … I had to reboot to get it back properly.

data loss? note hanging, so I noticed sometimes Id get hanging notes… Im not sure at this point if its a bug in MEC , or a an issue with rtpmidi having data loss (there are some errors in the logs).

anyway, rPI solutions have been a bit disappointing (at least for now) , so I think a hardware solution (mioXm) seems to be the way forward… either using the midi DIN on the rPI/PiSound or usb host on mioXm for ‘high volume’ data.

Id also need to try out rtpmidi on windows, hopefully that is a little more stable.

overall, I get the feeling rtpmidi is still a bit ‘bleeding’ edge, it works in tests, but start pushing it, and your milage may vary :wink:

1 Like

CoreMidi going bad can happen (from many causes!), I think killing /usr/sbin/coreaudiod will bring it back next time rather than rebooting.

I think you might need to lower expectations :wink:

It has been around quite a while, 2004 I think it started. The recent spec from 2011 is here https://tools.ietf.org/html/rfc6295

It looks like a simple protocol to implement, maybe time to roll your own?

1 Like

Also one thing to try with the WIFI timings is to send midi clock as well, I now it sounds counterintuitive but it might well lower your latency.

1 Like

yeah, the wifi latency didn’t seem that bad tbh, but in my setup it’ll just usually be as easy to have a hard wired ethernet (with switch) … but for sure, stuff that is not permanently connected/portable (e.g. organelle), id be happy to connect with wifi.

yeah, I know its been around ages, but it just does not seem to have been adopted/supported by many.
sure apple have it as part of coremidi, and it was given a bit of a boost/exposure due to iOS and people using iPads… but Linux, and windows you don’t really see much talk of it.
similarly theres not much on the hardware side… im pretty confident that iConnectivity will have done a solid implementations, so its an interesting 'gateway.

id be also interested in the cinaratech one as its pretty cheap (150eur), but given the unreliable nature of the software versions ive tried, im now a bit sceptical…

(BomeBox don’t use it, which is a pity)

so that’s what I mean by bleeding edge, it feels like its a technology that at some point could become an important part of a ‘modern studio’, but at the moment still feels immature (not in age, but in implementation?)

but… perhaps this is just because we are trying to push so much data through it.
(then again, that’s really one of the key advantages of using a network connection :wink: )

interesting/relevant article


I might also try this open source project…

code base looks pretty modern, doesn’t mention rPI, but I’m sure it’ll either work or could be made to work… its also seeing active commits, as its in dev.
so even if its not complete, it might be an interesting project to contribute too.

Yep looks mostly done apart from timestamps and the journal stuff which is optional anyway.

yeah ive got it compiling on rPI now (I’ll send a PR) , but its seems to have a few issues.
however, the code base is pretty easy to read, so I may look into seeing if I can contribute.

id like to have an open source variant, as then i can get it running on the Organelle :slight_smile:

other good news on rPI front.
been in touch with McLarenLabs , and they have pointed out a few solutions and workarounds to issues I was having… so ts now looking pretty good.

I’m getting some missed note_off messages , and some errors in the log, but hopefully we can get those resolved… Im also going to double check its not something thats happening on my side (in MEC)

as a side effect of this, I also think Ive found a possible optimisation in the MEC midi code… which will help many things :slight_smile:

so all in all, looking very promising… so going to order that mioXM now, then I can get this all hooked up and playing nicely together.

1 Like

things moving forward nicely…

did some changes to MEC yesterday which fixed a number of small issues,
MPE from Eigenharps feels pretty solid now.

investigated issues rtpmidi from McLarenLabs with Tom, think its clear where issue might be, so hopefully that can move forward.

Ive done some work (push back via PR) and testing on rtpmidid, and appears to be working well with MPE now - there’s a few things need tidying up, but it works.

so now, able to have Eigenharp Alpha/Tau connected to rPI, connected via ethernet to Mac, feels great, no appreciable latency.

so basically the setup im aiming for is:
Im going to have a rPI fo the Soundplane/Eigenharp that will act as ‘dongles’ that sit on the network,
then I can connect these ‘controllers’ to ‘sound engines’ that are sitting on the network.

sounds engines could be on mac, windows, rPI, Organelle which also exist directly on the network
hardware devices (controller or sound engine) will be connected to the same network via the mioXm.

the mioXm , is then where I do all the routing of controllers -> sequencers-> sound engines.

the idea with all of this, is that it’ll be then less faffing around for me to bring in various sound sources, and generative stuff thats running on things like supercollider on rPI and Bela. also things like my laptop can just be dedicated to running DAWs/plugins etc… and not worry about controllers.

mioXM should be here in a few days time, time to try it all out :slight_smile:


In one word? supercalifragilisticexpialidocious
Great ideas nicer plan :wink:

Sounds like good progress, did you get the mioXM yet?

Yeah, the MioXM is here and plugged in, also got a small network router/switch so music stuff is directly connect to that on its own network.
looking good so far - though not done any performance tests yet, as been busy with either stuff. But hope to get that done soon.

1 Like

I’d be interested when you get everything going of the details, it all sounds very usefull.

I spent a bit of time with it yesterday,

I’m still struggling a little bit with the rPI / Fates/ Norns,
I setup rtpmidid on them and whilst its working with a mac, seems to be having issues with mioXM… so im going to try ravelox and McLaren rtpmidi, but they had other issues :frowning:

so still a bit of work in progress…to get it all working.

on the positive side,
the way network sessions are broadcast makes things very easy to setup,.
mioXM is working great with windows and mac, just the rPI that’s having issues.
also generally the mioXM is very useful to me, the way just as centralised midi router.

1 Like

This looks cute - DIN MIDI to/from Bluetooth: https://www.cme-pro.com/
Not sure what they mean with ultra low latency though - really really fast or just less bad than usual?

“January 21, 2020 – First prototype latency min/max test: 4-10 ms depending on connected device” (https://www.cme-pro.com/how-to-connect-two-midi-hardware-via-wireless-bluetooth-midi/)

1 Like

I hope it doesn’t vary between 4-10 ms. That would be worse than any fixed value in that range.
10 ms sounds okish but not awesome.