김태민 3회기 AI 무음 2건 — 수신 패킷은 도착, 재생 샘플 960·0 정지 분석원인 미확정 · 수정 미적용

요약

1. 시간순 인과

// 2026-10-13 KST · 아동 단말 Android 10, Chrome 154 (모바일) · 진행자 세션 로그 없음(아카이브에 guest만)
21:05:52  AI 세션 c0738878 시작 (같은 페이지, 활동 전환)
          에이전트 패킷 수신 ○ 597 → 1043
          재생 샘플 960 고정  → 아동 스피커 ✗
          중계 송출 0bf2 0바이트 (21:05:58, 재확인 21:06:14) → 진행자 ✗     = 사건 ①
          그 사이 AI 발화 6회 (AI_SPEAKING_START)
21:07:04  페이지 로드 (재입장) → 21:07:08 warm-up → AI 세션 5e8d3238
          재생 샘플 1,416,960 → 2,856,960, 중계 송출 정상
21:07:21  AI "아니, 막 괴롭힐 마음은…" — 아동 못 들음
21:07:35  아동 발화 "소리가 안나."
21:07:45  도움 요청 "소리가 안 들려요" (ISSUE_DIAG: 출력 probe 정상)
21:07:46  중계 송출 audioLevel 0.23 → 진행자는 들음                    = 사건 ②
21:08:14  AI→AI 전환 → 세션 5f7688f6, 중계 송출 7469 0바이트
21:08:25  세션 종료 → 21:08:31 페이지 로드 → 세션 309529c4 정상
21:09:54  AI→AI 전환 → 세션 13e4981a, 재생 샘플 0, 중계 07f8 0바이트

2. 증거 — 받은 패킷 vs 재생 샘플

totalSamplesReceived는 재생 쪽이 꺼내 간 디코딩 샘플 누적이다. 48kHz라 1초에 48,000씩, 30초면 약 1,440,000 늘어난다. 960은 20ms, Opus 프레임 하나다. 첫 프레임만 꺼내고 그 뒤로 꺼내지 않았다는 뜻이다.

원본 위치

• LogRocket 아동 세션 export (6-01a13519-…_0_82e946dd-….json, 20:50:35~21:11:18) — webrtc stats 항목 inbound[0]. c0738878: 줄 89367/89374, 94019/94026 · 13e4981a: 149818/149824, 157555/157561 · 정상 309529c4: 128307/128314
• 세션 로그 lesson-log-20261013.jsonl.gz — Audio producer outbound stalled (ai-audio): af46 줄 1666·1673, 0bf2 4086·4307, 7469 5714, 07f8 7102·7345
• LiveKit 서버 로그(Loki): 모든 방에서 agent 트랙 mediaTrack published. "no worker available" 뒤 곧바로 assigned job to worker라 배정 실패 아님

2-1. 수신 통계 읽는 법 — c0738878 21:06:52

inbound는 아동 브라우저가 LiveKit에서 받는 쪽 AI 트랙의 통계(RTCInboundRtpStreamStats)다. 보내는 쪽은 outbound에 따로 있다.

LiveKit ──패킷──> [수신 ○] → [지터버퍼] ──✗ 요청 없음──> 디코딩·출력 없음
SFU ○  네트워크 ○  디코더 ○(보정 0)  렌더러 꺼내가기 ✗  출력 장치 ○(앞뒤 세션 정상)

2-2. 꺼내 가는 쪽 — audio 요소 하나 (Room AudioContext 아님)

• Room은 webAudioMix 없이 기본값으로 만든다(livekit-client-session.ts:2179-2182).
• livekit-client 2.22.4는 webAudioMix일 때만 원격 참가자에게 AudioContext를 넘긴다(livekit-client.esm.mjs:31380-31381, :31416-31417). 그래서 AI 트랙 attach는 WebAudio 연결(:26448)을 건너뛰고 <audio>.srcObject로만 재생된다.
• 무음 세션 요소 상태 muted:false, volume:1도 이와 맞다(WebAudio 경로였다면 LiveKit이 요소를 muted:true, volume:0으로 바꾼다).
• 엄밀히는 요소가 직접 꺼내 가는 것이 아니다. 요소가 재생을 시작하면 Chrome 내부 렌더러가 생기고, 그 렌더러가 출력 장치 시계에 맞춰 10ms마다 WebRTC(NetEq)에 요청한다. 요소는 그 렌더러의 스위치다.

요소 상태(paused:false, 재생 중)와 내부 렌더러 상태(요청 없음)가 어긋난 것이 관측의 전부다. 무엇이 어긋남을 만들었는지는 미확인이다.

3. 세션 전환 코드 경로

develop 1b9925e3(10/14) 기준. 사건 당일 배포 버전과 다를 수 있다.

stopSession (releaseAudioElement 기본 false)        use-ai-session.ts:1361
 ├ liveKitSession.disconnect()                      :1441
 │   └ TrackUnsubscribed → track.detach(el)         livekit-client-session.ts:3432
 └ pauseAndDetachAudio(): el.pause(); el.srcObject = null   use-ai-audio-output.ts:169-175
startSession
 ├ ensureAudioElement() → 같은 요소 반환           use-ai-audio-output.ts:132-150
 └ TrackSubscribed → audioTrack.attach(el) → play gate  livekit-client-session.ts:3322, :3373
     └ onRemoteAudioStream(new MediaStream([track])) → 진행자 중계 producer  :3402

• 요소 생성: 페이지당 처음 한 번, 첫 터치·클릭(guest-layout.tsx:425-426 → :130-134, hasWarmedUpRef)이나 "시작" 버튼(guest-layout-content.tsx:182-187)에서 warmUpAudio가 제스처 안에서 new Audio() + 빈 play()를 한다. 이번 로그의 warm-up 3회(21:00:10, 21:07:08, 21:08:35)가 이것이다.
• track.detach(el)는 기록만 지우지 않는다. 스트림에서 트랙을 빼고 남은 트랙이 없으면 srcObject = null로 만든다(detachTrack). 이어서 앱도 srcObject = null을 한 번 더 한다(중복). 새 세션의 attach는 새 MediaStream을 만들어 넣는다(attachToElement). 즉 재사용 세션에서도 요소의 스트림은 매번 비워졌다가 새로 들어간다.

4. 가설 판정

5. 대처 방안 — 재현 없이 안전하게 재출력 (제안, 미적용)

재현 환경을 만들 수 없으므로 원인을 먼저 확정하지 않는다. 정확히 감지했을 때만 가벼운 복구부터 시도하고, 단계별 결과를 로그로 남겨 고객 로그로 효과와 원인을 함께 검증한다.

감지 — 세션 내내, attach 후 1~2초 유예

1초 간격 2회 연속:
  packetsReceived 증가 > 0   &&   totalSamplesReceived 증가 = 0
  && outputBlocked = false  &&  AI 스텝  &&  visible
// 절대값(≤960) 판정은 세션 중간에 멈추는 경우를 놓친다 → 증가량으로 판정
// 비AI 스텝·출력 차단 중에는 앱이 일부러 play()를 하지 않아 샘플 0이 정상 → 반드시 제외
// 1초 폴링은 playout drift 모니터가 이미 한다: isIdleInterval(livekit-playout-drift-monitor.ts:195, 238-250) + packetsReceived(PPI-1374)

복구 단계 — 단계마다 1.5초 뒤 샘플 증가로 성공 판정

안전장치

• 재생은 반드시 재생 게이트로: 맨 play()를 부르면 비AI 스텝에서 꺼 둔 AI 소리가 영상 위로 흐른다(PPI-907 유형, use-step-transition.ts:236-258).
• 세션 유지 확인: 비동기 대기 뒤 같은 sessionAttempt·연결 유지·트랙 구독 유지를 확인한 뒤에만 attach. 끝난 세션 트랙을 다시 붙이지 않는다.
• 예외 처리: 직전 play() 약속이 남은 채 pause()되면 AbortError → catch 후 로그만.
• 횟수 제한: 세션당 단계별 1회, 쿨다운. 기존 drift 모니터 reset(livekit-client-session.ts:3350-3354, 현재 mode:'off')과 코드를 공유해 이중 동작을 막는다.
• 원격 스위치: 1차는 "감지 + 로그만"으로 오탐률을 본 뒤 복구를 켠다.
• 진행자 중계 확인: 복구 성공 뒤 ai-audio 중계 송출 바이트가 다시 흐르는지 함께 기록한다.

새 요소 생성 시 플랫폼별 재생 권한 (정책 기준, 실기기 미확인)

로그로 검증 (재현 대신)

단계마다 stage, 시도 전후 packetsReceived·totalSamplesReceived 증가량, 재생 게이트 결과, 중계 bytes, UA를 남긴다. "①에서 복구" 비율이 높으면 요소 상태 문제, "②에서 복구"면 요소 객체 문제, "③까지 감"이면 페이지 상태·권한 문제로 원인이 좁혀진다. 권장 순서는 감지·로그 + ① + ③ 먼저, 플랫폼별 play() 거부율을 본 뒤 ② 추가.

6. 이슈 분류기 반영

ppi-issue-classifier 정답지에 두 사례를 등록하고 판정 가드를 추가했다.

관련 문서

• 변유나 6회기 AI 음성만 무음 — 수신 샘플 0 (같은 증상, packetsReceived 미기록으로 구간 미확정)
• LiveKit 방 전환 레이스 — 아동 마이크·AI 오디오 무음 (빠른 AI→AI 전환, Room AudioContext 후보)
• PPI-1374 AI 발화 무음 구간 판별 진단 로그
• PPI-1192 iPad AI 발화 무음 — setSinkId 사용자 제스처