Has anyone tested the latency of a MIDI path through Bome Network vs. Direct?
(This testing is something I can do myself, but I’m loathe to rewire things as I have a show in 4 days)
I have choices in a few places between:
Bome MIDI Translator <=> Local USB Device vs.
Bome MIDI Translator <=> (Virtual MIDI Port) Bome Network <=> Local USB Device
… and in other places between:
Bome MIDI Translator <=> BMT Virtual MIDI Port <=> Process on the same Host vs.
Bome MIDI Translator <=> (Virtual MIDI Port) Bome Network (Virtual MIDI Port) <=> Process on the same Host
The advantage of adding Bome Network into the chain for me is that I can move the device or process to a different place in the MIDI network on a different host and everything works.
The downside is latency - of which WindSynth players are notoriously sensitive.
Hi, I’ve done some tests and found the latency of using Bome Network to be negligible. With that being said, anything going over a network would be subject to the network topology, congestion, and transport use (WiFi or ethernet). In general MIDI signals do not consume a lot of network bandwidth but if you have multiple audio or video streams on the same network, this could impact the latency. I also found out that certain network adapters on Mac don’t work very well (maybe the Mac drivers for certain chip sets). Ethernet will likely have lower latency than WiFi.
My tests involved sending MIDI from Bome MIDI Translator Pro and waiting for it to echo back (loopback). Then using timestamp of MT Pro to measure (no sub millisecond measurement) and then dividing the time it took by two (one way vs round trip). I generally only go through this exercise if someone is reporting a problem with a given configuration. This is how I discovered the issue with some USB to ethernet adapters.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
I’m actually looking at scenarios that do not involve additional network hops. Such as this comparison of a note played on my Sylphyo to get to my VL70 hardware synth:
Using Bome Network:
Sylphyo => Radio Link => Aodyo Link Receiver => USB => BNet
=> BMT on Atlas => BNet => USB => MIDI Interface =DIN> VL70
Direct to the devices:
Sylphyo => Radio Link => Aodyo Link Receiver => USB
=> BMT on Atlas => USB => MIDI Interface =DIN> VL70
The advantage of Bome Network is that I can move any of the hardware to any other host that runs Bome Network. However, when I’m not using this capability, I would still suffer the two round-trips through Bome Network for no gain.
I realized that I can test this without a re-wire job … I can do two routes from my Sylphyo to two identical soft synths, routing one through Bome Network and routing the other direct, and just record the two outputs. This will show the different between the two and give a read on the latency introduced by Bome Network. Have to wait till next week … have a show on Sunday …
When I do tests like this, I record in Reaper and can easily zoom in and compare the timing of two tracks at a sample level - so it’s precise (and hopefully accurate) to 1/48 of a msec at 48kHz.
So I took a stab at testing Bome MIDI Translator (BMT) and Bome Network (BNet) latency. It was a spectacular and unmitigated failure.
I’ve done tests like these before at the audio interface level, and they were very helpful at reducing latency.
I did not have to measure the Source-to-sound latency, all I had to do (HA!) was compare the differences between various paths. Basically my 4 test paths were:
A. MIDI IN => Surge XT => Reaper
B. MIDI IN => BMT ==Virtual MIDI Port>> Surge-XT => Reaper
C. MIDI IN => Bome Network ==Unliminated Named MIDI Port>>
Surge-XT => Reaper
D. MIDI IN => Bome Network ==Unliminated Named MIDI Port>>
BMT ==Virtual MIDI Port>>Surge-XT => Reaper
This should have produced 4 side-by-side recordings in Reaper from the 4 instances of Surge-XT I had running. A should certainly be the fastest, and D the slowest, because of the intervening hops taken by the MIDI.
Sadly, the results appeared rather random (!!). Sometimes, sound from Paths B, C, and D arrived earlier than Path A. I am guessing that it has something to do with process scheduling for the different instances of Surge-XT, or contention with ‘simultaneous’ MIDI input, or some other concurrency issue.
I think that perhaps the plugin adds latency when converting MIDI to audio. You might want to try to test just the MIDI latency to factor out the latency added by any receiving item that needs to convert MIDI to audio.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
My standard test tool for this is to record parallel streams in Reaper. This works well for Audio, but not for MIDI.
I have found (the hard way) that when MIDI passes through an ASIO interface, it ‘rides along’ with the audio buffer. This introduces a variable delay that matches the size of the Audio buffer, because the MIDI arriving at the ASIO interface could arrive when the buffer is just starting to be filled with audio samples, or arrive when the buffer is almost full of audio samples.
The result is … MIDI jitter that depends on the size of the buffer. So, for a 48 sample buffer at 48kHz, that’s 1msec of jitter.
I have built a set of specialized MIDI + Audio Y-cables that have MIDI-In, MIDI-Out, and an unbalanced (TS) Audio Out. Pretty simple - a could of resistors if I recall - and I get a sharp audio pulse when the MIDI passes through.
What I could do, I guess, is to take the output of my 4 paths and send them to 4 MIDI outputs rather than into Surge. Then use my cables to record the Audio pulses in Reaper. The issue with this may be that the MIDI gets serialized in the output MIDI interface, affecting the test. The MIDI may also be getting serialized on the input side … another issue … Ugh.
I think I read somewhere that the human ear can only detect something over 10ms of latency or higher. Many cannot detect more the 20-30ms. Out of curiosity, what are you trying to solve with your measurements?
Audio latency for someone 20 feet away from you in a physical room would be about 20ms. So a band playing together on a fairly good size stage would need to be able to bear that amount during a performance unless they have IEM that have less latency.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
I think those ‘Human Ear’ quotes don’t really apply to ‘Human Fingers’ - especially if you’re playing a WindSynth. My experience is that reducing latency by only a few msec - 3 or 4 - produces a noticeable improvement when playing fast runs or ornaments (trills or mordents).
I’ve been playing a lot lately with headphones (as I did this past Sunday). However, the radio receiver for my WindSynth (an Aodyo Link) has a huge range - like 3 blocks. I’ve had fun walking away from the stage and getting longer and longer latency from the Main speakers.
Why I am doing this? … I have some routing choices in the way I set things up. Taking a MIDI hop through Bome Network makes some things more convenient, but at the cost of that extra In and Out through Bome Network. I wanted to know the cost of that hop before deciding how to set things up …
My informal latency measurements suggest these latency ballparks (one-way):
Bome virtual MIDI ports: ~10 microseconds, jitter at about 1 microsecond
Bome Network via Ethernet: ~330microseconds, jitter +/-50microseconds
USB-MIDI: ~1,500ms, jitter +/-500microseconds
USB-MIDI is (usually) polled at 1ms intervals, hence the jitter. But even the seemingly high USB latency and jitter are not noticeable for performers.
Disclaimer: although I took great care with the test setup to get accurate results, many factors play a role and may have altered the results. But the ballparks should be correct.
PS: I’m using a similar DIY setup for latency measurements. But you may risk your soundcard if you feed the 5V MIDI signal directly to a line input. Scaling it down to 1V with resistors is a good idea…
