🎧 모니터 측 게스트 마이크/AI 오디오 무음 원인 분석

근본 원인 게스트 use-guest-page-session.ts:904 의 aiSession.guestMicStream ?? localMedia.audioStream fallback 패턴이 AI 세션 시작/종료/재시작 때마다 micStream 참조를 바꿔, use-mediasoup-producer.ts:463-536 mic-audio useEffect 가 producer 를 close → recreate 함 (producer churn).

직접 원인 호스트 use-mediasoup-consumer.ts:322-341 의 resume-consumer 응답이 Consumer not found 일 때 재시도 없이 그냥 catch 에서 warn 만 찍고 종료. cascade close race 를 흡수할 방어선이 없음.

관전 포인트 "ping 저하" 가설은 로그에서 확인되지 않음 — 게스트 send transport, 호스트 recv transport 모두 disconnected/failed 한 번도 안 됨. 자동 reconnect 로직 발동 흔적 없음. 네트워크 문제가 아니라 코드 race 문제.

BT 무관 BT 는 출력(헤드폰) 쪽이었고 입력(마이크)은 Realtek 내장. producer churn 은 입력 측 race 라서 마이크가 어떤 디바이스든 동일하게 발생함.

Producer Churn = mediasoup producer 가 짧은 시간 안에 close → recreate 를 반복하는 현상. 이번 케이스에선 240ms 안에 id-034 가 생성→close→id-035 생성됨.

발화 코드 — use-mediasoup-producer.ts:463-536:

useEffect(() => {
  if (!isReady || !sendTransportRef.current || !micStream) return;
  produceMicAudio();                          // 새 producer 생성

  return () => {                              // cleanup
    const producer = producersRef.current.get("mic-audio");
    if (producer) producer.close();           // ← producer 닫음
  };
}, [isReady, micStream, roomId, peerId]);   // ← micStream 변경 시 cleanup→재실행

그리고 그 micStream 을 만드는 use-guest-page-session.ts:904:

micStream: aiSession.guestMicStream ?? localMedia.audioStream

use-ai-session.ts 의 guestMicStream 라이프사이클:

• 초기: null → fallback localMedia.audioStream 사용
• startSession() 안 처리 체인(gain → gate → EQ → compressor → limiter) 통과 후 setGuestMicStream(relayStream) (line 1599-1601)
• stopSession() 또는 재시작 정리 시 setGuestMicStream(null) (line 1333)

→ AI 세션이 한 번 끊겼다 재시작될 때 null → 새 stream 또는 stream → null → 새 stream 으로 prop 참조가 바뀜 → useEffect cleanup→재실행 → producer churn.

호스트의 enqueueConsume 가 new-producer 이벤트를 직렬화 처리 — use-mediasoup-consumer.ts:477-491.

실패 흐름:

1. 호스트가 consume(id-034) 호출 → 서버: producer 살아있어서 consumer id-040 생성, success 응답
2. 호스트가 recvTransport.consume(opts) 로 클라이언트 측 Consumer 객체 생성 ✅
3. 호스트가 resume-consumer 보내는 사이 (수십 ms) 게스트가 producer id-034 를 close
4. mediasoup 서버: producer close → consumer cascade close (표준 동작) → id-040 삭제
5. 서버가 resume 요청 받음 → Consumer id-040 not found 응답
6. 호스트 코드 — use-mediasoup-consumer.ts:332-337:

if (response.success) {
  resolve();
} else {
  console.error(`Failed to resume consumer ${consumer.id}:`, response.error);
  reject(new Error(response.error));        // ← throw
}

throw 는 enqueueConsume:482-487 의 catch 로 흘러감:

.catch((error) => {
  console.warn(`Failed to consume producer ${producerId}:`, error.message);
});                                          // ← warn 만 찍고 끝, retry 없음

mediasoup 서버는 producer 가 close 되면 그 producer 를 consume 중인 모든 consumer 를 자동으로 close 합니다. 이는 mediasoup 표준 동작 으로 코드 문제가 아닙니다. 문제는 클라이언트가 이 cascade 와 충돌하는 짧은 race 창문을 만들어내고, 그 race 를 흡수할 retry 가 없는 것.

호스트 로그상 대체 consumer id-052 는 정상 처리됐는데도 사용자는 그 이후 마이크 입력을 못 들었다고 함. 가능 원인:

1. 게스트 측 producer id-035 의 RTP send stats — bytesSent, packetCount 가 증가했는지. 무음 가설 ① 검증.
2. 호스트 측 consumer id-052 의 RTP receive stats — bytesReceived, packetsLost, jitter. 가설 ① 검증.
3. 호스트 audio element 의 srcObject 변경 트레이스 — Added mic audio track 이후 실제로 audio.srcObject 가 새 MediaStream 으로 갱신됐는지. 가설 ② 검증.
4. 호스트 AudioContext 상태 — state === "running" 인지, 또는 suspend 됐는지. 가설 ③ 검증.
5. 10:02:13 AI 세션 재시작 트리거 — wasActive=false 의 진짜 의미. step 전환 vs OpenAI Realtime drop vs 다른 원인.
6. 호스트가 force kick 누른 정확한 UI 행위 로그 — kick 누르기 직전 호스트 UI 상태 (audio meter, AI speaking indicator, 게스트 카메라 등) 확인.

🟡 (모니터링) 호스트 — Inbound Audio 무음 감지

현재는 mediasoup transport state 만 보고 "정상" 판단함. 다음 추가:

• consumer 의 RTP stats 폴링 — bytesReceived 가 일정 시간(예: 3~5초) 증가하지 않으면 alarm
• 혹은 Web Audio API AnalyserNode 로 inbound stream 의 RMS 측정 — 일정 threshold 이하 지속 시 무음 alarm
• 호스트 UI 에 "게스트 마이크 무음" 인디케이터 표시 → 호스트가 강퇴 대신 정확한 액션 가능

🟢 (호스트 UX) MFCC 부하 완화

• MFCC 분석을 Web Worker 로 격리 (메인스레드 영향 제거)
• 또는 stale event 일정 임계치 초과 시 분석 일시 정지 + UI 인디케이터는 transport state 기반으로 fallback
• "통신 끊김" UI 를 mfcc lag 와 분리 — 진짜 끊김(connectionState=disconnected/failed) 일 때만 표시