Audio Scheduling: Why Rhythm Games Stopped Being Broken in Browsers

Rhythm games used to be one of the genres that simply did not work in browsers. The audio latency was inconsistent; the scheduling was unreliable; the difference between hitting a note exactly on the beat and missing by 50ms was the difference between "good" and "broken" gameplay. Browsers could not deliver the tight timing the genre needs.

That situation has changed over the past five years. The Web Audio API has matured, browser implementations have stabilised, and rhythm games are now viable in browsers. This piece walks through what changed and what it means for the games on the catalogue at Flux Frame, with notes from profiling work I did on rhythm titles during Cork Cork commuter rail commutes.

The original Web Audio problem

The original Web Audio API was designed for general-purpose audio playback. The API let JavaScript trigger audio events through a high-level audio graph. The implementation, especially on mobile browsers, had two problems that broke rhythm games specifically.

First, the latency from "JavaScript triggers a sound" to "speakers produce the sound" was variable. The variance was usually 20-80ms but could spike higher under load. For rhythm games, 80ms of variable latency is a death sentence; the player cannot reliably hit a beat that arrives at a different time on different attempts.

Second, the audio scheduling was tied to JavaScript timing. The audio event fired when JavaScript got around to it, which depended on the rest of the game's frame work. A frame that took a few extra milliseconds to process delayed the audio. Frame drops produced audio glitches.

Both problems made rhythm games feel sloppy compared to native equivalents.

The audio context worker scheduling

The Web Audio API solved this through a feature called audio context scheduling. The API allows JavaScript to schedule audio events at specific future timestamps, and the browser commits to firing the audio at exactly that time, independently of what JavaScript is doing.

The pattern works like this. The game knows the BPM of the track and the timing of each beat. The game scheduler runs ahead of the playhead, scheduling the next ten seconds of audio events into the audio context. Each event has a precise timestamp. The audio context fires them on schedule regardless of frame drops or JavaScript pauses.

This pre-scheduling pattern removes the latency variance entirely. The latency from "JavaScript schedules a sound" to "speakers produce the sound" is the same on every fire because the audio context handles the firing. Frame drops in JavaScript no longer affect audio because the audio is already queued.

Input scheduling

The complementary problem is input scheduling. The player taps the screen at a specific moment; the game records the tap timestamp; the timestamp gets compared to the expected beat timestamp. If the input timestamp is unreliable, the comparison is unreliable, and the rhythm game falls apart.

Modern browsers timestamp input events at the operating-system level rather than at the JavaScript level. The timestamp on a touch event reflects when the touch was registered by the OS, not when JavaScript got around to processing it. This timestamping is precise enough for rhythm games.

Combined with the audio scheduling, this lets rhythm games work in browsers the same way they work natively. The player taps; the input timestamp gets recorded; the timestamp gets compared to the expected beat; the result is consistent across frame drops and JavaScript pauses.

The remaining latency budget

There is still some end-to-end latency. The audio output buffer adds 10-20ms of fixed latency in most browsers. The display refresh adds 8-16ms of latency for visual feedback. Touch input has 30-80ms of additional latency on phones.

Rhythm games account for these latencies through calibration. The first time you play, the game offers a calibration screen where you tap to a beat and the game measures your effective latency. The calibration value gets applied to all future input comparisons, making the perceived timing match the actual timing.

Most current rhythm games on the catalogue at Flux Frame have calibration screens. The games that skip calibration usually feel slightly off on mobile compared to desktop; the games that include calibration feel right on both.

What this means for browser-game design

The audio scheduling improvement does not just enable rhythm games. It also raises the bar for audio quality in non-rhythm browser games. Audio cues that signal events can now arrive on time consistently; sound effects sync with their visual counterparts; ambient music loops without audible seams.

The catalogue at Flux Frame reviews audio quality explicitly when it affects the experience. Games that take advantage of modern audio scheduling earn ratings appropriate to their audio polish. Games that ignore the improvements often feel cheap audio-wise even when their visuals are strong.

What this means for you as a player

If you used to avoid rhythm games in browsers because they felt off, try them again. The format works now. Tested on Cork Cork commuter rail commutes with calibration, the rhythm titles on this catalogue play as well as their native equivalents on most modern phones.

The improvement is broader than rhythm games. Any game with timed audio cues benefits from the better scheduling. The audio polish in current browser games is the highest it has ever been; the technology finally caught up to the design ambition.