Why does my music game feel off only on some devices?

Almost always audio output latency, especially over Bluetooth, which can add a hundred milliseconds or more and varies by device. Capture the audio output path and the calibration offset on every timing report. Flag Bluetooth reports specifically, because that latency is large and variable and is the most common cause of an it feels off complaint that is not a code bug.

A player swears they hit the note on time but it read as a miss. How do I check?

Capture both timestamps: the scheduled time of the note and the time the input was registered after the calibration offset is applied. Compute the actual error in milliseconds and see where it fell relative to your timing windows. That turns a subjective dispute into a measurement, showing whether the windows are too tight, the offset is wrong, or there is unhandled latency in the pipeline.

How do I tell a constant offset from gradual audio drift?

Capture the position in the song where the timing felt wrong. A constant offset feels wrong from the start, while drift gets worse the longer a track runs, with reports clustering near the end of long songs. Drift usually means the note chart and audio are on separate clocks; driving the chart from the audio clock gives both one shared source of truth.

Bug Tracking for Music and Instrument Games

Quick answer: Music and instrument game bugs are almost all timing bugs: audio latency, input latency, and calibration drift that turn a perfectly played note into a miss. Track them by capturing the calibration offset, the device and audio output path, and the timestamps of the expected note versus the registered input, so you can measure the gap instead of guessing whether the player or the pipeline is at fault.

In a music or instrument game, the entire experience hinges on a few milliseconds. A note played in perfect time has to register as a hit, and if your pipeline adds latency anywhere between the player and the judgment, a flawless performance reads as a string of misses. Players feel this instantly even when they cannot name it, and they will report that the game is off without being able to say by how much. The bugs here are latency, input timing, and calibration, and tracking them means measuring time precisely. This post covers how to do that.

Latency is the whole ballgame

Every music game fights latency on two fronts. Audio output latency is the delay between when the game decides to play a sound and when the player actually hears it, and it varies wildly across speakers, headphones, and especially Bluetooth, which can add a hundred milliseconds or more. Input latency is the delay between the player acting and the game registering it. Both shift the apparent timing of a note, and if either is unaccounted for, accurate play scores as inaccurate.

You cannot fix latency you do not measure. Track timing bugs by capturing the audio output path, whether it is built-in speakers, wired headphones, or a Bluetooth device, alongside the calibration offset in effect. Bluetooth reports especially should be flagged, because the latency it adds is large and variable and is the single most common cause of an it feels off complaint. Knowing the output path on each report lets you separate a genuine pipeline bug from the unavoidable physics of a wireless audio device.

Calibration and per-device offsets

Because latency differs by device, every serious music game offers calibration: the player adjusts an offset until taps line up with the beat. Calibration itself is a frequent source of bugs. An offset that does not persist between sessions, a calibration screen that measures the wrong direction, or a default offset that is badly wrong for common hardware will all make the game feel broken to a player who assumes it should just work out of the box.

Track calibration bugs by capturing the stored offset, when it was last set, and the device it was set on. If a player calibrates and the game still feels off, you need to know whether the offset saved, whether it is being applied with the correct sign, and whether it survived a restart. Capturing the offset on every timing report also lets you spot when a particular device class needs a better default, so most players land close to correct before they ever open the calibration screen.

Judging a hit: expected versus registered time

The core of the game is the judgment: comparing when a note was supposed to be hit against when the input actually arrived, and the bug reports all come down to disputes about that comparison. A player insists they hit the note on time and the game called it a miss. To resolve that you need both timestamps, the scheduled time of the note and the time the input was registered, after the calibration offset has been applied.

With both timestamps you can compute the actual error in milliseconds and see exactly where it fell relative to your timing windows. This turns a subjective it was on time into an objective measurement: the input landed thirty milliseconds late after offset, which is outside your perfect window. From there you can tell whether the windows are too tight, the offset is wrong, or there is real latency in the pipeline that calibration is not catching. The two timestamps are the most valuable thing a music-game bug report can carry.

Chart sync and audio drift

Even with latency and calibration handled, a song can drift. If the note chart and the audio playback are driven by separate clocks, they slowly fall out of sync over a long track, so the start feels perfect and the end feels wrong. This is distinct from a constant offset; it is a gradual divergence, and players describe it as the song falling apart toward the end. It usually means the chart is following frame time while the audio follows the audio clock.

Track drift by capturing the position in the song where the timing felt wrong, not just that it felt wrong. If reports cluster near the end of long tracks, or grow worse the longer a song runs, you are looking at drift rather than a fixed offset, and the fix is to drive the chart from the audio clock so both share one source of truth. Capturing the song timestamp on every report is what lets you distinguish a steady offset from a creeping drift.

Setting it up with Bugnet

Bugnet is a good fit for music games because the in-game report button captures state automatically the moment a player feels the timing is wrong. You can attach the calibration offset, the audio output path, the device, and the expected-versus-registered timestamps for the disputed note as custom fields. That turns a vague the timing is off into a measurable report: you can see the actual error in milliseconds and whether the player was on a Bluetooth device, which is exactly the context you need to separate a real bug from wireless audio physics.

Since many players on the same hardware feel the same timing issue, Bugnet folds duplicate reports into one issue with an occurrence count, so a device class that needs a better default offset rises to the top. You can filter by the audio output path or by device to isolate Bluetooth-only complaints, or by song position to spot chart drift on long tracks. One dashboard with the timing data attached lets you fix calibration defaults and judgment windows from evidence rather than from a pile of subjective complaints.

Testing timing the way players feel it

The studios that nail rhythm games test timing on real, varied hardware, because the bugs live in the pipeline differences between devices. A timing pass on your dev machine with wired headphones proves almost nothing about a player on a phone with cheap Bluetooth earbuds. Build a test matrix of audio output paths and devices, measure the actual latency each adds, and confirm your calibration defaults land players close before they touch a setting.

Treat the millisecond as your unit of truth. When a report comes in, read the measured error, not the adjective the player used, and let the occurrence counts tell you which device classes need attention first. A music game earns devotion when a perfectly played note feels perfectly judged, and you get there by measuring time precisely, fixing the pipeline where it drifts, and giving players a calibration that actually works.

In a music game the millisecond is the unit of truth. Capture the offset, the audio path, and both timestamps, and read the measured error instead of the adjective.