TTS 재생 스톨 — onended 미발생으로 인한 재생 큐 영구 블로킹 원인 분석 원인 분석 수정 필요

1. 요약

• 무반응 구간에도 OpenAI 응답 생성(response.create → Response completed)은 매번 1초 미만 정상
• 무반응 구간에도 Typecast TTS fetch는 0.5~1.1초로 계속 성공, 디코딩까지 완료
• 스톨 트리거는 기기(iPad) 런타임/오디오 정지로 추정되나, 몇 초짜리 장애를 세션 강제 재접속까지 확대시킨 책임은 tts-player의 무방비 설계에 있음 (watchdog 부재, onended 단일 의존, iOS interrupted 미처리)

2. 조사 대상 세션

두 세션 모두 스톨 전후로 기기·네트워크 불안정 정황 동반: 킥 직후 NETWORK_QUALITY "외부·서버 모두 도달 실패(인터넷 전체 다운)" 진단, critical NetworkAlert(cameraVideo·cameraAudio·socket), 재입장 시 PermissionDenied 반복.

3. TTS 파이프라인 구조 — 공급과 소비의 분리

AI 응답 텍스트는 스트리밍 델타로 들어와 문장 경계에서 청크로 잘려 큐에 쌓인다 (appendDelta → sentence_boundary / max_buffer / finalize). 각 청크는 병렬로 합성(fetch)·디코딩되지만, 재생은 큐 맨 앞부터 한 번에 하나다.

4. 스톨 타임라인 — 세션 A 킥#1 (00:31:07 ~ 00:31:46)

진행자 메시지에 대한 AI 응답(턴 d3173c00, 10글자+7글자 청크 2개)에서 발생. 막대 길이는 실제 로그 타임스탬프 비율.

이벤트 로그 요약

5. 재발 패턴 — 세션 A 킥#2, 세션 B

세션 A 킥#2 (00:32:38 ~ 00:33:30) — 메인스레드 정지의 결정적 증거

• "잘 지냈어 너는?" 응답 청크1(14글자)이 또 10.1초 재생 (00:32:39.014 → 00:32:49.153)
• 같은 순간(00:32:49.15x) 청크2의 fetch 응답 콜백(10,074ms)도 동시에 해빙 — 메인스레드가 ~10초 얼었다 깨어난 서명. LogRocket에서 "10초짜리 TTS 응답"으로 보였던 유일한 1건의 실체가 이것 (네트워크 지연 아님)
• 청크2 재생 시작(00:32:49.504) → onended 미발생 → 진행자 {{듣기실패1차}}(00:33:01), -다시 말해줘(00:33:18) 응답 모두 수신만 되고 재생 안 됨 → 41초 침묵 → 킥

세션 B (01:03:55 ~ 01:04:30)

• 세션 시작 후 첫 3턴은 정상 재생 (글자당 ~0.25초 비율)
• "응" 응답 청크1(12글자)이 01:03:55.632 재생 시작 → 시작 직후부터 onended 미발생 (전조 없이 즉사 — suspended/interrupted 상태로 start했을 가능성)
• 진행자 {{듣기실패1차}}, {{재접속안내}} 응답 수신·디코딩 성공, 재생 0회 → 35초 침묵 → 킥(01:04:30) → critical NetworkAlert(01:04:38) → 재입장 시 권한 오류 반복으로 수업 중단

6. onended "지연"과 "미발생"의 구분

확인 방법: LogRocket 내보내기 JSON의 TTS chunk playback started / ended를 diagnostic의 traceId + chunkIndex로 짝 맞추고 타임스탬프 차를 계산. "미발생"은 세션 정리(Stopping session) 시점까지 짝이 없음 + 그 사이 다른 로거는 정상 간격으로 계속 찍힘(로그 수집 유실 배제) + 콜백을 무효화하는 generation 증가는 킥 시점에만 발생함으로 교차 검증. 기대치 기준은 같은 세션 정상 청크들의 글자당 0.2~0.4초 비율.

7. tts-player 코드 취약점

스톨의 트리거는 기기(iPad) 런타임/오디오 정지지만(전 로거 동시 공백, 콜백 동시 해빙, 네트워크 진단이 근거), 몇 초짜리 환경 장애가 영구 블로킹이 된 것은 코드 구조 때문이다.

// tts-player.ts:397 — 재생 중이면 어떤 호출도 무시 (resume 라인까지 못 감)
private tryPlayNext(): void {
  if (this.disposed || this.playing) return;
  ...
  if (ctx.state === "suspended") ctx.resume().catch(() => {});  // fire-and-forget
  ...
  source.onended = () => { ... this.finishCurrentPlayback(gen, metadata); };  // 유일한 진행 경로
  source.start();  // resume 완료를 기다리지 않음
}

8. 재발 시 로그 판별법

1. [TTS_PLAYER] TTS chunk playback started 이후 같은 traceId·chunkIndex의 playback ended가 수십 초간 없음 → 스톨 확정
2. 그 사이 TTS chunk queued / response received / audio decoded가 계속 쌓임 → 공급 정상 + 재생 블로킹 (TTS API 문제 아님)
3. started→ended 간격이 clientTextLength × 0.3초 대비 3배 이상 → 전조 (런타임 정지)
4. 전 로거 ~10초 완전 공백 후 여러 콜백 동시 해빙 → 메인스레드 정지 서명
5. 주변 정황: Received message from host: {{듣기실패1차}}(현장 무음 방증), Guest force kicked(스톨 종료점), NETWORK_QUALITY/NetworkAlert(기기 환경)

9. 수정 방향

관련 문서: iOS 덕킹 TTS/Realtime 모드 감쇠폭 차이 원인분석, 아동070 1회기 아동 소리 안 들림 원인분석, 영상 종료 자동전환 미발생 Watchdog 분석 (비디오 쪽 watchdog 선례)