연구·해설 / 기술 문헌 읽기
웹 오디오 예약, JavaScript 타이머와 오디오 시계의 역할
콜백이 깨어난 시각과 소리를 내기로 한 시각을 나누면 웹 오디오 예약의 역할이 보인다. 기술 글의 25ms 호출·100ms 예약 예제를 자체 시간축에 옮겨 지연에 대응하는 범위와 복귀 조건을 살펴본다.
기사 요약
- 짧게 검사하고 미래 오디오 사건을 예약한다.
- 호출 지연이 예약 범위를 넘는 경우도 계산한다.
- 완성곡 재생과 개별 사건 시퀀서를 나누어 설계한다.
Web Audio API 1.1 · 2026-09-22 Working Draft
오디오 소스가 처리 노드를 거쳐 출력으로 흐르는 구조다. 호출·예약 시점은 아래 자체 시간축이 설명한다.
이미지 출처: W3C Web Audio Working Group · W3C 문서 라이선스 · 제공 페이지 ↗ · 원본 ↗ · 문서 라이선스 ↗
타이머를 깨우는 일과 소리를 내는 시각을 나눈다
음악 사건을 화면 타이머가 깨어난 순간마다 즉시 재생하면 콜백 지연이 소리의 시점에 반영된다. Chris Wilson의 기술 글은 짧은 간격으로 실행되는 스케줄러가 오디오 시계의 미래 사건을 미리 예약하는 방식을 설명한다. 이 자료는 기술 해설 글이며 연구 논문과 구분한다.
스케줄러의 역할은 앞으로 필요한 사건을 찾아 오디오 시각으로 예약하는 것이다. 화면 갱신과 사용자 입력도 같은 음악 기준을 읽되 각각의 역할을 가진다.
관련 원자료: Chris Wilson · A tale of two clocks ↗
25ms 호출과 100ms 예약을 다른 값으로 읽는다
원문과 MDN 예제는 호출 간격 25ms, 앞서 예약할 범위 100ms를 사용한다. 하나는 다음에 검사할 간격이고 다른 하나는 지금 확보할 미래 시간이다. 실행 부하와 실시간 조정의 반응을 비교하며 값을 정하는 출발 예제다.
자체 시간축의 첫 검사는 0ms에[0,100) 범위를 예약한다. 다음 호출이예정 25ms에서 55ms로 늦어져도 80ms 사건은 이미 예약돼 있다.55ms 검사에서는[55,155) 범위의 미처리 사건 120ms를 예약할 수 있다.
관련 원자료: Chris Wilson · A tale of two clocks ↗ · MDN · Creating and sequencing audio ↗
같은 숫자에 서로 다른 역할을 적는다
| 값 | 역할 | 자체 예제 |
|---|---|---|
| 25ms | 호출을 요청할 간격 | 실제 도착은 55ms일 수 있음 |
| 100ms | 한 번에 예약할 미래 범위 | 첫 범위[0,100) |
| 80ms | 오디오 사건의 목표 | 첫 검사에서 예약 |
| 120ms | 다음 사건의 목표 | 후속 검사가 제때 필요 |
DJMAX RESPECT V · 공식 PC판 화면
노트와 판정선의 공간 배치를 보여 주는 실제 플레이 화면이다. 예약 정확도와 지연은 실행 기록의 별도 확인 대상이다.
콜백이 늦어져도 확보한 미래 구간을 읽는다
편집부 작성 도표 · 첫 검사 0ms, 다음 검사 55ms 또는 130ms인 자체 예제.
가로축: 오디오 경과 0~200ms. 막대=예약 범위, 원=사건, 삼각형=실제 검사.
작은 화면에서는 도표를 좌우로 밀어 볼 수 있다. 도표 크게 보기 ↗
도표의 값과 읽는 순서
- 첫 범위[0,100):80ms 예약
- 55ms 검사:[55,155)에서 120ms 예약
- 130ms 검사:120ms 목표를 지나 늦은 사건 정책 필요
예약 범위를 넘는 지연도 계산한다
다음 검사가 130ms까지 지연되면 첫 범위 밖의 120ms 사건은 이미 목표 시각을 지났다.80ms 사건은 앞서 예약됐지만 120ms 사건은 늦은 사건 정책이 필요하다. 이 모형은 한 번의 예약이 모든 미래를 보장하는 범위를 명확히 보여 준다.
지연 사건을 즉시 재생할지 생략할지, 다음 박으로 옮길지는 제품 규칙이다. 오디오 기준 목표와 실제 예약 시각, 지연 원인 자료를 남겨 경계 조건을 검증한다.
완성곡 재생과 사건 시퀀서를 구분한다
고정된 곡 파일을 한 소스로 재생하면 파일 안의 드럼마다 화면 타이머로 다시 소리를 낼 필요가 없다. 곡의 원점과 파일 위치를 기준으로 노트·판정·표시를 계산한다. 악기 사건을 따로 합성하는 시퀀서는 미래 사건을 계속 예약하는 구조가 필요하다.
두 구조 모두 정지·복귀·속도 변화의 기준을 정의한다. 예약 범위가 길수록 미래 변경을 반영할 책임도 커진다. 이미 만들어진 소스와 예약을 어떻게 정리할지 기록한다.
관련 원자료: Chris Wilson · A tale of two clocks ↗
완성곡과 사건 시퀀서의 역할
편집부 작성 도표 · 고정곡과 개별 악기 사건을 재생하는 두 구조의 개념 비교.
열: 입력 자료→재생 구조→음악 기준을 읽는 표시.
작은 화면에서는 도표를 좌우로 밀어 볼 수 있다. 도표 크게 보기 ↗
도표의 값과 읽는 순서
- 완성곡:파일 소스→파일 위치→노트·표시
- 시퀀서:사건 목록→미래 오디오 예약→진행 표시
화면은 같은 기준을 읽어 그린다
스케줄러는 소리를 예약하고 화면은 현재 음악 위치에서 활성 목표와 진행도를 계산한다. requestAnimationFrame은 표시를 갱신하는 계기다. 오디오 노드 라우팅 그림은 소리가 흐르는 경로이고, 여기의 시간축은 예약 시점을 설명한다.
DJMAX 사진에서 노트·판정선·결과 영역을 관찰할 수 있지만 정밀한 예약 동작은 코드와 실행 기록에서 확인한다. 프레임 간격과 입력 사건, 오디오 기준을 함께 기록해 어느 연결이 달라졌는지 조사한다.
관련 원자료: MDN · Creating and sequencing audio ↗
중단·복귀·지연을 나눠 시험한다
정상 호출,55ms 지연,130ms 지연의 작은 사건표부터 검사한다. 다음에는 중단 시점의 저장 위치, 이미 예약된 소스의 정리, 새 원점과 중복 예약 방지를 확인한다. 재개 버튼의 연속 입력도 한 번의 재생으로 처리되는지 살핀다.
모형 계산 뒤 지원 기기에서 실제 소리와 입력을 확인한다.25·100ms를 보편적인 승인값으로 고정하기보다 호출 지연과 조정 반응의 기록으로 선택 근거를 남긴다.
작은 시간축으로 확인할 조건
| 조건 | 80ms 사건 | 120ms 사건 |
|---|---|---|
| 0ms 검사 후 55ms 검사 | 기존 예약 | 55ms에 사전 예약 |
| 0ms 검사 후 130ms 검사 | 기존 예약 | 지연 정책 적용 |
| 중단 후 재개 | 기존 소스 정리 | 새 기준에서 중복 없이 예약 |
출처·확인 범위
2026.10.17 원문의 Scheduling ahead와 25/100ms 예제, MDN Playing the audio in time 절을 확인했다.80·120ms 사건과 55·130ms 지연은 원리를 설명하기 위한 자체 계산이다. 실기기 성능 측정 결과와 구분한다.