USB Polling Rate for Gamepad MIDI: 125 Hz vs 1000 Hz

Polling rate is the number everybody quotes and almost nobody sources. You will see "1000 Hz polling" on a product page, "125 Hz is why your pad feels sluggish" in a forum reply, and a chart somewhere ranking controllers by a figure with no methodology attached. The underlying mechanism is genuinely simple, genuinely specified, and genuinely useful to understand — and it is also a much smaller slice of your total press-to-sound time than the internet implies. This post traces the number back to the USB specification, works out what it means for a gamepad-to-MIDI chain, and is honest about where it stops mattering.

What is a USB polling rate, mechanically?

USB is a host-scheduled bus, which means devices never transmit spontaneously — the host asks, and the device answers. A gamepad's input data travels on an interrupt IN endpoint, and interrupt endpoints are the mechanism USB provides for "low-latency, guaranteed-bandwidth, small-payload" traffic exactly like button and axis state. The host commits to issuing a transaction to that endpoint at least once per requested period, which is what people call the polling rate.

The requested period lives in a single field of the endpoint descriptor: bInterval. The device declares it, the host scheduler reserves bandwidth for it, and from that moment the cadence is fixed for the life of the connection. This is why you cannot simply "turn polling up" on a stock controller — the number is not a setting on your computer, it is a term in a contract the device wrote.

Where do 125 Hz and 1000 Hz actually come from?

From USB's frame structure, which is defined in the USB 2.0 specification. Full-speed buses are divided into frames of 1 millisecond. High-speed buses subdivide each frame into eight 125 microsecond microframes. Those two durations are the specification constants everything else is derived from, and they are the only hard numbers in this post that are not arithmetic.

How bInterval is interpreted depends on which of those two worlds the endpoint lives in:

Device speed	bInterval meaning	bInterval = 1	bInterval = 4	bInterval = 8
Full speed	Direct count of 1 ms frames	1 ms (1000 Hz)	4 ms (250 Hz)	8 ms (125 Hz)
High speed	Exponent: period = 2(bInterval-1) microframes of 125 µs	125 µs (8000 Hz)	1 ms (1000 Hz)	16 ms (62.5 Hz)

So the famous 125 Hz is a full-speed device asking for bInterval 8, and the famous 1000 Hz is a full-speed device asking for bInterval 1. Neither is a measurement. Both are the reciprocal of a scheduling period derived from a frame duration written into the USB spec. That is worth stating plainly, because latency content on the open web routinely presents them as though someone put a controller on a scope and got those figures out.

How do I find out what my controller is asking for?

Linux exposes it directly, and this is the fastest way to answer the question for any pad you own:

# Tree view with bus speeds - tells you full speed vs high speed
lsusb -t

# Full descriptor dump - find the interrupt IN endpoint and read bInterval
sudo lsusb -v -d 054c:0ce6 | grep -A 6 "Endpoint Descriptor" | \
     grep -E "bEndpointAddress|bmAttributes|wMaxPacketSize|bInterval"

# Typical interrupt IN endpoint on a gamepad
#   bEndpointAddress     0x84  EP 4 IN
#   bmAttributes            3        Transfer Type: Interrupt
#   wMaxPacketSize     0x0040  1x 64 bytes
#   bInterval               4

On macOS, System Information under USB shows the device speed, and IOKit exposes the endpoint properties programmatically through the families documented in the IOKit reference. On Windows, Device Manager in "view by connection" mode tells you the speed of the controller the device sits behind, and USBView from the WDK shows the full descriptor set including bInterval.

The interpretation question — frames or microframes — is answered by the speed, not the descriptor. A full-speed device behind a high-speed hub is still a full-speed device. Getting this backwards is how people end up claiming a pad polls at 8000 Hz.

What does polling interval actually bound?

One thing: the maximum time between a state change inside the controller and the host being handed a report containing it. If the interval is T, and your button closes immediately after a poll completes, you wait nearly a full T before the host can know. If it closes just before, you wait nearly nothing. Averaged over random press timing, the expected wait is about half the interval, and the worst case is the full interval.

That gives you a clean, defensible way to reason about the difference between settings without inventing measurements. Going from an 8 ms interval to a 1 ms interval removes up to 7 ms of worst-case wait at that stage. Whether you perceive 7 ms depends entirely on what the other stages cost, and that is where the honest conversation starts.

• USB polling interval
• Bridge processing
• Virtual MIDI port
• DAW input handling
• Audio buffer and output

Why is polling rate a small part of what you feel?

Because the press-to-sound chain has several stages and the polling stage is rarely the largest. The chain looks like this:

Stage	What sets its timing	Can you change it?
Switch closes, controller MCU scans it	Firmware scan rate and debounce logic	No, unless the firmware exposes it
Report waits for the next transfer	bInterval and bus speed	Only if the device supports it
Host hands the report to your process	OS scheduler and driver stack	Partly, via thread priority and event-driven reads
Bridge converts to MIDI, writes to a virtual port	Your code plus the virtual MIDI driver	Yes
DAW receives the MIDI event	Host MIDI thread and its own scheduling	Rarely
Synth renders a sample block	Audio buffer size and sample rate	Yes, and this is usually the biggest knob
Interface converts and outputs	Converter latency	No

Note the second-to-last row. Audio buffer size is the stage most producers can change, and changing it moves the total by an amount that is usually larger than the entire polling question. We walk through tuning the whole chain in order in which stage is actually slowing you down and in the latency tuning docs. If you only have one evening, buffer size first, polling second.

For an end-to-end figure on real hardware, this site ran its own measurements and published them in the gamepad MIDI latency benchmark. Those are this site's numbers on this site's rig with this site's methodology, and they should be cited that way rather than treated as a universal constant.

Does polling faster give me higher resolution?

No, and conflating the two is the most common mistake in this area. Resolution — how many distinct values an axis can express — is set by the Logical Maximum declared in the HID report descriptor, as covered in HID report descriptors explained. Polling rate only controls how often you are told the current value.

A stick with an 8-bit declared range polled at 1000 Hz still has 256 steps. Polling it 8 times more often gives you 8 times more samples of the same 256-step staircase. What that does buy you is a better basis for filtering: a smoothing filter has more data to work with, so you can suppress sensor noise with less added lag. That is a real benefit, but it is a signal-processing benefit, not a resolution one. The filter side is covered in stick smoothing filter algorithms.

Should the bridge send a MIDI message every poll?

Definitely not, and this is where polling rate crosses over from a hardware topic into a design decision you control. If you read at 1000 Hz and emit a CC on every read, you are generating up to a thousand messages per second per axis. Two sticks moving at once makes that four thousand.

MIDI 1.0 on a 5-pin DIN cable runs at 31,250 bits per second, a rate specified in the MIDI 1.0 core specification. With the standard asynchronous framing of one start bit, eight data bits and one stop bit, each byte occupies ten bit periods, so a three-byte Control Change message occupies thirty bit periods. At 31,250 bits per second that is just under a millisecond per message — which means a DIN cable physically cannot carry much more than about a thousand three-byte messages per second in total, across all channels. Flood it and messages queue, and queued messages are late messages. That is arithmetic on a published spec rate, and it is the reason DIN MIDI rigs choke on stick sweeps that USB rigs shrug off. We go deeper into the bandwidth maths in MIDI's 31,250 baud explained.

USB MIDI and virtual ports are not bound by the DIN wire rate — the USB Device Class Definition for MIDI Devices packetises MIDI into 32-bit USB-MIDI event packets carried at USB speeds — but your DAW still has to parse and act on every message, and your automation lanes still have to store them. The practical rule is to emit on meaningful change only:

// Read at the device rate, send at a sane rate
static uint8_t last_sent[128];
static uint64_t last_send_us[128];

void axis_updated(int cc, double normalised, uint64_t now_us) {
    uint8_t value = (uint8_t)lround(normalised * 127.0);

    // 1. Suppress unchanged values outright
    if (value == last_sent[cc]) return;

    // 2. Rate-limit per controller number, not globally
    if (now_us - last_send_us[cc] < MIN_SEND_INTERVAL_US) return;

    midi_send_cc(cc, value);
    last_sent[cc]    = value;
    last_send_us[cc] = now_us;
}

The first check alone removes the overwhelming majority of traffic, because a 7-bit CC derived from a steady stick produces the same value poll after poll. The second check protects you during fast sweeps, where every poll genuinely does produce a new value.

Is event-driven reading better than timer-driven polling?

Yes, and it is the single most valuable change most bridges can make. If your loop sleeps for a fixed period and then reads, you have added a second, independent sampling stage on top of the USB one — and because your timer and the bus schedule are not synchronised, the two beat against each other and produce avoidable timing spread.

Every platform offers an event-driven path. On macOS, Apple's GameController framework delivers value-changed callbacks, with the per-element handlers documented on GCPhysicalInputProfile and GCControllerButtonInput. On Linux, evdev file descriptors are pollable and block until a real event arrives, as described in the kernel input event codes documentation. On Windows, GameInput readings are timestamped and can be consumed as they arrive, which is a meaningful improvement on XInputGetState's pure snapshot model. The trade-offs between those stacks are laid out in GameInput versus XInput for MIDI.

What about Bluetooth — does polling rate even apply?

Not in the USB sense. Bluetooth Low Energy has no bInterval; it has a connection interval, negotiated between the two devices and expressed in units of 1.25 ms by the Link Layer, as specified in the Bluetooth Core Specification. The peripheral may also use peripheral latency to skip connection events it has nothing to say in, which saves battery and costs responsiveness.

Two consequences follow. First, the interval is negotiated rather than declared, so the same controller can behave differently on two different hosts — and host Bluetooth stacks have genuinely different negotiation policies. Second, the minimum connection interval the Core Specification permits is substantially longer than USB's minimum frame period, so wireless input sits in a different timing regime by construction. That is a mechanism argument, not a measurement, and it is the right way to talk about it. Bluetooth MIDI for gamepads and wired versus Bluetooth cover the practical consequences, and the Bluetooth connection docs cover setup.

What should I actually change, in what order?

1. Audio buffer size. Lower it until the CPU complains, then back off one step. Biggest single move available to most people.
2. Wired over wireless. USB's scheduling floor is shorter and its variance is smaller than BLE's by construction.
3. Event-driven reads. Stop adding your own sampling stage on top of the bus schedule.
4. Send-on-change with per-CC rate limiting. Reduces downstream work everywhere, costs nothing perceptible.
5. Polling interval, if the device supports changing it. Real, bounded, and smaller than the first item.
6. Everything else. Process priority, USB hub topology, disabling power management on the port.

Notice that the thing the internet talks about most is fifth on that list. That is not a reason to ignore it — it is a reason to fix the four above it first and then measure, rather than buying a controller because a chart said 1000 Hz. The methodology for measuring your own chain, rather than trusting a chart, is in how to read a controller latency chart.

FAQ

What does a 1000 Hz polling rate actually mean?

It means the host requests an input report from the device once every millisecond, because 1000 Hz is simply the reciprocal of a 1 ms polling interval requested through the endpoint descriptor.

Is 1000 Hz polling better than 125 Hz for MIDI?

It lowers the worst-case wait between a physical movement and the host learning about it, but it is only one stage of a chain that also includes audio buffering, so it rarely dominates the total you perceive.

Where does the 125 Hz figure come from?

From a bInterval of 8 at USB full speed, where the interval is counted in 1 ms frames, giving an 8 ms period which is 125 reports per second.

Can I force my gamepad to poll faster?

Not reliably, because the interval is requested by the device in its endpoint descriptor and honoured by the host controller, so raising it requires firmware changes or a driver that overrides the descriptor.

Does a higher polling rate increase stick resolution?

No, resolution is set by the Logical Maximum declared in the HID report descriptor, while polling rate only controls how often you are told the current value.

Should my MIDI bridge send a CC on every poll?

No, you should send only on meaningful change, because sending unchanged or imperceptibly different values at the full poll rate floods the MIDI stream and bloats automation lanes without improving feel.

Put it into practice

Run lsusb -v or open USBView, find the bInterval on your pad's interrupt IN endpoint, and work out what interval it is actually asking for. Then go and halve your audio buffer. One of those two numbers is going to move what you feel far more than the other, and now you know which. Download Universal Controller MIDI and set send-on-change in the mapping editor before you touch anything else.