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. 링크된 출처 자료는 각자의 권리를 유지합니다.