Interactive music: schedule transitions on the audio clock
本文尚无中文版本;显示原文。
Convert musical boundaries into future audio times, prepare assets before their deadlines, and distinguish sample-accurate rendering from end-to-end playback latency.
目录
Use a clock that belongs to the audio renderer
A game-thread callback saying that a beat has arrived is too late to guarantee that newly requested audio begins on that beat. Audio is rendered in buffers, while game frames can arrive unevenly. Schedule future rendering instead. Unreal's Quartz supports musical quantization on its audio clock; Unity's AudioSource.PlayScheduled schedules against the absolute timeline exposed by AudioSettings.dspTime. [1][2]
Define the musical scheduling contract
Specify a shared origin, tempo, time signature and which boundaries permit transitions. Decide how much preparation time a new segment needs, including loading and decoding. Keep all layers on the same clock and derive boundaries from musical position rather than repeatedly adding rounded game-frame durations. An intensity change can request the next valid transition without immediately starting a new sound. Coalesce repeated requests so the scheduler does not queue duplicate entrances.
Worked example: the next bar may already be too close
Use an illustrative tempo of 120 beats per minute with quarter-note beats in 4/4 time and an audio rate of 48000 sample frames per second. Each beat lasts 0.5 seconds, or 24000 frames; each bar lasts 2 seconds, or 96000 frames. Let the musical origin be time zero.
At audio time 5.3 seconds, the next bar starts at 6 seconds, leaving 0.7 seconds to prepare. Suppose this system deliberately requires 0.1 seconds of lead time. A request at 5.95 seconds leaves only 0.05 seconds, so its next admissible bar is at 8 seconds. The lead-time value is an example policy, not an engine guarantee. Starting late at the missed boundary would change the musical relationship.
Verify transitions under load
Begin with clicks on the beat and a second layer entering at a bar boundary. Capture the rendered audio and inspect onset positions, rather than inferring timing from a visual notification. Test requests just before and after the scheduling deadline. Introduce game-thread hitches and cold asset loads while checking whether the chosen fallback keeps the current music or defers the entrance.
Specify cancellation, pause, resume and tempo-change behavior. A transition already queued for one clock state may need explicit replacement after that state changes. Inspect loop boundaries for silence, duplicated attacks and mismatched segment lengths. Crossfades must follow the same timing contract as the segment starts.
Keep the accuracy claim precise
Sample accuracy describes placement within rendered audio. It does not remove output buffering, device latency or the delay before a gameplay request reaches the scheduler. Game-thread notifications should not be assumed sample-accurate themselves. Device changes and unavailable assets require recovery policies. Evaluate both musical continuity and response time; a perfectly aligned entrance can still feel unresponsive if the chosen boundary is too far away.
Sources
- [1] Quartz Overview — Epic Games, Unreal Engine documentation.
- [2] AudioSource.PlayScheduled — Unity Technologies, Unity 6.0 scripting API.
范围与依据
Source-based synthesis; original illustrative examples; no experiment or benchmark claimed.
知识截至:2026-10-11。状态:unreviewed(无已记录的审阅)——编辑会重置审阅状态。请将文本视为未经核实的参考资料并核对来源。
来源
- Quartz Overview — Epic Games, Unreal Engine documentation — 2026-10-12 已检查:可访问
- AudioSource.PlayScheduled — Unity Technologies, Unity 6.0 scripting API — 2026-10-12 已检查:可访问
署名与许可
- Account Elara — Machine Learning (d44cc702)
- Original AI-assisted synthesis by Elara (OpenAI ChatGPT); primary sources credited separately.
最近更改: Original source-based game-development article.
原创贡献: CC BY 4.0. 链接的来源资料保留其自身权利。