"There is latency" is the most common complaint in software MIDI and the least useful, because the press-to-sound path has at least seven stages and people almost always blame the wrong one. The virtual MIDI port gets accused constantly and is rarely guilty. This guide walks the chain stage by stage, says which control affects which stage, and gives you a tuning order so you fix the big contributors before fiddling with the small ones.
- Tune in this order: audio buffer → connection type → poll rate → thread priority → everything else.
- The DAW audio buffer is typically the largest stage and the one nobody checks first.
- Wired removes the radio stage. Bluetooth is fine for sweeps, wired for percussive playing.
- The virtual port hop is small on all three operating systems — it is not your problem.
- Random spikes are a driver problem, not a MIDI problem. No MIDI setting fixes those.
Do virtual MIDI ports add latency?
The virtual port hop is one of the smallest stages in the chain on all three operating systems — your DAW audio buffer and, if you are wireless, the radio transport dominate the total far more.
This matters because it redirects effort. If you spend an evening swapping virtual MIDI drivers while running a 512-sample buffer, you are optimising a small stage and ignoring a large one. The stages below are ordered by how much they typically contribute, and the tuning order follows directly from that.
What are the stages between a press and a sound?
Seven, and each one has its own control — the complete breakdown, including wired-versus-wireless figures, is maintained in our latency tuning documentation.
| Stage | What happens | Which control changes it | Worth tuning? |
|---|---|---|---|
| Controller scan | The device builds its HID report | None — it is the hardware | No |
| Transport | USB poll or Bluetooth connection interval | Use a cable instead of radio | Yes — big |
| OS input driver | Kernel delivers the report | None directly | No |
| Bridge poll cycle | The app reads controller state | Poll rate, 500 or 1000 Hz | Yes — modest |
| MIDI encode | Bytes packed and queued | Disable timestamps if unused | Marginal |
| Virtual port to host | CoreMIDI / WinMM / ALSA hop | Avoid unnecessary network hops | Rarely |
| DAW audio buffer | Host renders a block of audio | Buffer size and sample rate | Yes — usually the biggest |
- Controller scan
- Transport
- OS input driver
- Bridge poll
- MIDI encode
- Virtual port
- DAW audio buffer
What buffer size should I use?
Start at 128 samples and drop to 64 if your machine handles it without audio dropouts; 512 is comfortable for mixing but noticeably rubbery for performing.
Set this first, before touching anything MIDI-related, and test with the thing you actually struggle with — if finger drumming feels late, test finger drumming, not a filter sweep. Many people run a large buffer for mixing and never change it back for performance, which is a perfectly reasonable workflow as long as you know that is what is happening.
- Mixing and arranging: 256 or 512. Plugin headroom matters more than feel.
- Recording and performing: 128, or 64 on a capable machine.
- Driving outboard gear with no DAW in the chain: the buffer stage does not apply at all.
- Driving visuals: a 60 fps frame budget is far coarser than any audio buffer — you have headroom to spare.
Is USB lower latency than Bluetooth?
Yes — a wired connection removes the radio transport stage entirely, which is why wired is the default recommendation for percussive playing while Bluetooth remains perfectly usable for sweeps and pads.
The more important property is consistency rather than raw speed. A constant small delay is something your playing adapts to within minutes. A delay that varies is the thing that makes a rig feel unreliable and ruins takes. Radio links are inherently more variable than cables because they share a congested band with everything else in the room — which is exactly the environment a venue provides. Our Bluetooth MIDI latency deep dive covers the jitter sources in detail.
Practical rules:
- Percussive playing: wired, always.
- Sweeps, pads and ambient: wireless is fine and the mobility is worth more.
- Live performance: wired primary, wireless as the hot spare. Hot-swap failover covers the switchover.
- Crowded RF environment: assume the radio will be worse than it is at home, and plan for it.
What does the poll rate actually change?
It sets how often the bridge reads controller state, so it bounds the worst-case gap between a physical movement and the MIDI event that represents it.
{
"poll_hz": 1000,
"deadzone": 0.04,
"scheduler_priority": "high",
"midi_buffer_size": 64
}The default is 500 Hz; 1000 Hz halves the worst-case gap. Do not go higher — most controllers report internally somewhere between 250 and 1000 Hz, so polling faster just spins the CPU. The tell-tale symptom of over-polling is the fan spinning up with no change in feel.
How do I stop other software stealing the CPU?
Promote the bridge's thread priority so its poll loop runs when it is scheduled to rather than queueing behind a background process.
# macOS — check the QoS class on the running poll thread
ps -M $(pgrep -x ucm) | awk '{print $5, $6, $7}'
# Linux — raise scheduling priority and pin to a core
sudo chrt -f -p 80 $(pgrep -x ucm)
sudo taskset -p 0x2 $(pgrep -x ucm)# Windows — High is correct here; Realtime starves other processes
Get-Process ucm | ForEach-Object { $_.PriorityClass = "High" }A 1000 Hz poll loop means nothing if a browser tab monopolises the core for thirty milliseconds. On macOS the equivalent setting is the user-interactive QoS class in Settings → Performance — the same priority bucket a DAW uses for its audio engine.
Why does my latency spike randomly on Windows?
Random spikes usually come from driver-level interruptions rather than MIDI — a misbehaving wireless or GPU driver shows up in a DPC latency tool and no MIDI setting will fix it.
The diagnostic signature is distinctive: everything is fine for minutes at a time, then one event lands dramatically late, then it is fine again. That pattern is not produced by buffer size or poll rate, both of which are consistent by nature. Run a DPC latency monitor, identify the offending driver, and update or disable it. This is a system-health problem that happens to be visible through MIDI.
Does routing to two hosts make it worse?
Not in the MIDI path, because the fan-out happens inside the bridge before the virtual ports, so each host receives its own copy rather than queueing behind the other.
What does change is system load — you are now running two hosts, each with its own buffer and its own plugins. If feel degrades after adding a second host, check buffers and background load rather than the routing itself. Setup details are in routing one controller into two DAWs.
The tuning order, in one list
Work down this list and stop when it feels right, because every step below the one that fixed it is wasted effort.
- Audio buffer — 512 to 128, or 64. Biggest single win, most often overlooked.
- Connection — swap Bluetooth for USB.
- Poll rate — 500 Hz to 1000 Hz. Never above.
- Thread priority — user-interactive on macOS, High on Windows,
chrton Linux. - Remove extra hops — no network session if a local port will do.
- Deadzone — tidy the stream so the host is not processing jitter.
- Timestamps — disable if you are triggering live rather than recording tightly.
- System health — DPC latency, background processes, power profiles.
Frequently asked questions
Do virtual MIDI ports add latency?
The virtual port hop is one of the smallest stages in the chain on all three operating systems — your DAW audio buffer and, if you are wireless, the radio transport dominate the total far more.
Why does my MIDI feel laggy even though the port is local?
Almost always the DAW audio buffer, which is typically the largest single contributor to press-to-sound time, so check that before touching any MIDI setting.
What buffer size should I use for playing MIDI live?
Start at 128 samples and drop to 64 if your machine handles it without audio dropouts; 512 is comfortable for mixing but noticeably rubbery for performing.
Is USB lower latency than Bluetooth for a controller?
Yes — a wired connection removes the radio transport stage entirely, which is why wired is the default recommendation for percussive playing while Bluetooth remains fine for sweeps and pads.
Should I raise the poll rate above 1000 Hz?
No, because most controllers report internally at 250 to 1000 Hz, so polling faster burns CPU without producing any perceptible improvement.
Why does my latency spike randomly on Windows?
Random spikes usually come from driver-level interruptions rather than MIDI — a wireless or GPU driver misbehaving will show up in a DPC latency tool and is not something a MIDI setting can fix.
Put it into practice
Fix the buffer, plug in a cable, raise the poll rate, promote the thread. That sequence resolves the overwhelming majority of "there is latency" reports, and it takes about five minutes — considerably less than an evening spent swapping virtual MIDI drivers that were never the bottleneck.
Download Universal Controller MIDI to get the poll-rate, priority and deadzone controls plus a Visualise tab that shows event timing live, so you can see which change moved which number. Next: the full latency tuning reference or MIDI port troubleshooting if the problem turns out not to be timing at all.