오디오 파이프라인 해부 — 마이크부터 스피커까지, 코덱·RTP·Jitter Buffer

마이크 (아날로그)
   ↓
ADC (Analog to Digital Converter)
   ↓
PCM (디지털 오디오 데이터)

마이크: 공기 진동 → 전기 신호 (연속적, 아날로그)
ADC:    전기 신호 → 숫자 (이산적, 디지털)
PCM:    그 숫자들의 나열

ADC는 OS/하드웨어 레벨에서 이미 처리됨.
우리가 제어하는 건 PCM 이후.

그래서 시스템 설계에서는 보통 이렇게 표현합니다:

  Mic → PCM → processing → encoding

ADC는 "있다"는 것만 알면 충분합니다.

PCM (원본)
  ↓
AEC (Acoustic Echo Cancellation)
  → 스피커에서 나온 소리가 마이크에 다시 들어가는 것 방지
  → 화상회의에서 "에코" 현상 제거

  ↓
AGC (Automatic Gain Control)
  → 볼륨 자동 조절
  → 작게 말해도 적당히, 크게 말해도 적당히

  ↓
NS (Noise Suppression)
  → 배경 노이즈 제거
  → 키보드 소리, 에어컨 소리 등

  ↓
전처리된 PCM

PCM 그대로 보내면:

  PCM (16bit, 48kHz, mono) ≈ 768 kbps
  Opus 인코딩 후            ≈ 16~64 kbps

  → 거의 10~40배 차이

PCM은:
  ✅ 용량 큼
  ✅ 품질 좋음
  ✅ 계산/처리는 쉬움
  ❌ 네트워크에 올리면 비쌈 + 느림

→ 그래서 압축(인코딩) 필요

┌─────────────────────┬─────────┬──────────────────────────────────┐
│ 상황                │ 코덱    │ 이유                             │
├─────────────────────┼─────────┼──────────────────────────────────┤
│ WebRTC / 라이브 통신 │ Opus    │ 저지연, adaptive, 패킷 손실 대응 │
├─────────────────────┼─────────┼──────────────────────────────────┤
│ 전화 / SIP / PSTN   │ µ-law   │ 초경량, CPU 거의 안 씀, 레거시  │
├─────────────────────┼─────────┼──────────────────────────────────┤
│ VOD / 저장 / HLS    │ AAC     │ 고음질, 압축 효율, 스트리밍 표준 │
├─────────────────────┼─────────┼──────────────────────────────────┤
│ 간단한 웹 다운로드   │ MP3     │ 호환성 최고, 구형 시스템 포함    │
└─────────────────────┴─────────┴──────────────────────────────────┘

Opus
  - 실시간 최강
  - adaptive bitrate (네트워크 상태에 따라 자동 조절)
  - 패킷 손실에도 복구 가능
  - latency 매우 낮음
  → 라이브용. WebRTC = 거의 무조건 Opus.

µ-law
  - 매우 가벼움 (lookup table 수준)
  - CPU 거의 안 씀
  - 음질 낮음 (8bit, 8kHz)
  → 레거시 전화용. WebRTC에서는 거의 안 씀.

AAC
  - 고음질
  - 같은 bitrate에서 MP3보다 더 좋은 음질
  - HLS, MP4 필수급 표준
  → 콘텐츠 배포용. 유튜브, 넷플릭스, HLS 전부 AAC.

MP3
  - 호환성 최고
  - 구형 시스템 포함 어디서든 재생
  → fallback + 범용.

1. 실시간인가?
   → YES → Opus

2. 전화망인가?
   → YES → µ-law

3. 저장/스트리밍인가?
   → YES → AAC

4. 호환성이 가장 중요한가?
   → YES → MP3

TCP:
  정확하지만 느림
  패킷 유실 시 재전송 → 지연 발생

UDP:
  빠름
  일부 손실 허용

실시간 통신은:
  정확성보다 "지연"이 더 중요

  0.5초 전 소리를 정확히 듣는 것보다
  지금 소리를 대충이라도 듣는 게 나음

→ UDP 선택

오디오/영상 실시간 전송 프로토콜.
UDP 위에서 동작하면서 부족한 부분을 보완합니다:

  sequence number → 패킷 순서 관리
  timestamp       → 타이밍 동기화

UDP는 순서/타이밍 보장이 없으므로
RTP가 이 정보를 헤더에 추가합니다.

인코딩된 오디오 데이터:
  ↓
RTP 패킷으로 포장 (헤더 + payload)
  ↓
UDP로 전송

지터 = 패킷 도착 시간의 흔들림

정상:  10ms  20ms  30ms  40ms  (일정한 간격)
지터:  10ms  35ms  15ms  50ms  (들쭉날쭉)

순서 문제가 아니라 "시간 간격이 불규칙"한 것.
그대로 재생하면 → 끊김, 찢어짐, 로봇소리

지터 버퍼가 하는 일:

1. 패킷 도착 (들쭉날쭉)
2. 버퍼에 잠깐 쌓음
3. 일정 간격으로 꺼내서 재생

도착:     2   1   3
버퍼:     [1   2   3]     ← 순서 정렬
재생:     → → →           ← 일정 간격으로 출력

핵심:
  "도착 기준"이 아니라
  "재생 타이밍 기준"으로 바꾼다

TCP식 사고 (정확성 우선):
  순서 틀리면 기다림
  빠진 거 재요청
  → 결과: 느림

Jitter Buffer (부드러움 우선):
  조금만 기다림
  늦으면 그냥 포기
  대신 끊김 방지

한 줄: "완벽한 데이터"보다 "부드러운 재생"이 목표

버퍼 작으면:
  장점: 지연 낮음 (빠름)
  단점: 끊김 많음

버퍼 크면:
  장점: 안정적
  단점: 지연 증가 (느림)

┌──────────────────┬───────────┐
│ 상황             │ 선택      │
├──────────────────┼───────────┤
│ 게임 / 통화      │ 작은 버퍼 │
│ 방송 / 스트리밍  │ 큰 버퍼   │
└──────────────────┴───────────┘

네트워크 상태를 보고 자동 조절:

네트워크 안정 → 버퍼 줄임 → 지연 낮아짐
네트워크 불안 → 버퍼 늘림 → 안정성 확보

WebRTC, Agora 모두 adaptive jitter buffer를 사용합니다.

1. NACK (재전송 요청)

  클라이언트: "sequence 123 없어!"
  SFU:        "그거 다시 보내줄게"
  → 빠른 재전송

2. FEC (Forward Error Correction)

  미리 여분 데이터를 추가해서 전송
  데이터 + 복구용 패킷
  → 일부 loss는 재전송 없이 클라이언트에서 복구

3. PLC (Packet Loss Concealment)

  클라이언트에서:
    이전 프레임 복사
    보간(interpolation)
  → "티 안 나게 숨김"

4. Bitrate Adaptation

  네트워크 안 좋으면
  → SFU가 낮은 bitrate stream 선택해서 전달
  → 끊기는 것보다 화질 낮추는 게 나음

SFU = 전달 + 힌트 제공자
복구 = 클라이언트 + 프로토콜(WebRTC)이 담당

클라이언트 수신 전체 흐름:

UDP packet 도착
  → jitter buffer 저장
  → 순서 정렬
  → missing 있으면 NACK 요청
  → 복구(FEC) or 숨김(PLC)
  → 디코딩
  → 재생

UDP 수신
  ↓
RTP depacketize (헤더 제거, 오디오 데이터 추출)
  ↓
Jitter Buffer (흔들림 보정)
  ↓
Opus decode → PCM (압축 해제)
  ↓
DAC (Digital to Analog Converter)
  ↓
스피커 (전기 → 공기 진동 → 소리)

📡 송신 (보내는 쪽)

  Mic
    ↓
  ADC
    ↓
  PCM
    ↓
  Audio Processing (AEC, AGC, NS)
    ↓
  Opus 인코딩 (압축)
    ↓
  RTP packetize
    ↓
  UDP 전송

📡 수신 (받는 쪽)

  UDP 수신
    ↓
  RTP depacketize
    ↓
  Jitter Buffer
    ↓
  Opus decode → PCM
    ↓
  DAC
    ↓
  Speaker

일반 WebRTC:
  Client A → STUN/TURN → Client B (P2P 또는 SFU)

Agora SD-RTN:
  Client A → 가까운 Edge PoP → 최적 경로 선택 → Edge PoP → Client B

Edge ↔ Edge 사이:
  전 세계 PoP들이 full mesh 형태로 연결
  각 PoP가 다른 PoP로 가는 경로 성능을 계속 측정
  실시간으로 더 좋은 경로를 자동 선택

사용자 패킷 수신
  → 가까운 Edge에 들어감
  → Edge가 loss / RTT / jitter / congestion 상태를 봄
  → "지금 제일 괜찮은 경로" 선택 (필요하면 우회)
  → 수신 측 Edge에서 클라이언트로 전달

원본을 압축 포맷으로 바꾸는 것.

raw video → H.264
raw audio (PCM) → AAC

이미 인코딩된 스트림을 다른 해상도/비트레이트/포맷으로 바꾸는 것.

1080p 6Mbps → 720p 3Mbps
1080p 6Mbps → 480p 1.2Mbps

→ 다양한 네트워크 환경에 대응 (Adaptive Bitrate)

인코딩된 비디오/오디오를 HLS용 조각 파일로 만드는 것.

H.264 + AAC
  → segment-0001.ts
  → segment-0002.ts
  → index.m3u8

→ CDN에서 배포 가능한 형태

RTMP push는 인코딩된 H.264/AAC 스트림을
실시간으로 CDN ingest endpoint에 전달하는 과정입니다.

OBS / 인코더
  ↓ RTMP push (H.264 + AAC, TCP 기반)
CDN Ingest Endpoint
  ↓ 수신
HLS 패키징 (TS 세그먼트 + m3u8)
  ↓
Edge 캐싱
  ↓
사용자 재생

핵심:
  RTMP = 단순히 "입력 프로토콜" (스트림을 밀어넣는 파이프)
  CDN  = 받은 스트림을 HLS로 패키징 -> edge에 캐싱 -> 배포

→ RTMP 자체는 시청자에게 직접 전달되지 않음
→ CDN이 HLS로 변환해서 배포하는 구조

비유:
  RTMP = 택배 박스
  WebRTC = 오토바이 퀵배송

  물건은 같고 (영상/음성)
  포장 방식만 바뀐다

전체 흐름:

OBS (RTMP push)
  ↓
Agora Media Gateway (RTMP ingest)
  ↓
디코딩 또는 트랜스코딩
  ↓
WebRTC용으로 재패키징 (RTP/UDP)
  ↓
클라이언트 (WebRTC)

1) OBS → RTMP (업로드)

  Video (H.264) + Audio (AAC)
    → RTMP (TCP 기반)
    → Agora ingest 서버

  이건 그냥 "방송 업로드". 여기까진 단순함.


2) Media Gateway (핵심)

  여기서 진짜 일이 일어남. 서버가 두 가지를 합니다:

  (A) 디코딩 (필요한 경우)

    H.264 → raw frame
    AAC   → PCM

    왜?
      bitrate 조절이 필요할 때
      해상도 변경이 필요할 때
      여러 시청자 대응 (Adaptive Bitrate)

    코덱이 같으면 디코딩 없이 passthrough도 가능.


  (B) 재패키징 (항상 필요)

    WebRTC는 RTMP를 못 먹습니다.
    RTMP = TCP 기반 스트림
    WebRTC = RTP/UDP 기반 패킷

    그래서:

    RTMP stream (TCP)
      → 미디어 데이터 추출
      → RTP packet으로 재포장 (WebRTC format)
      → UDP로 전송

    "RTMP → WebRTC 프로토콜 변환" (X)
    "미디어를 꺼내서 → WebRTC 방식으로 다시 싸서 보냄" (O)


3) 클라이언트 (WebRTC 수신)

  RTP depacketize
    → Jitter Buffer
    → 디코딩 (H.264 → frame, Opus → PCM)
    → 렌더링/재생

  여기서부터는 일반 WebRTC 수신과 동일.

RTMP 스트림 내부 구조:

RTMP
  → FLV container
     → tag (video/audio)

각 FLV tag:
┌──────────────┐
│ type         │ ← video / audio
│ timestamp    │ ← 시점
│ data         │ ← H.264 NAL units 또는 AAC frames
└──────────────┘

파싱 = tag를 읽어서 type에 따라 H.264 또는 AAC 데이터를 꺼내는 것

MTU (Maximum Transmission Unit)
= 네트워크에서 한 번에 보낼 수 있는 최대 패킷 크기

Ethernet MTU ≈ 1500 bytes
IP header    ≈ 20 bytes
UDP header   ≈ 8 bytes
RTP header   ≈ 12 bytes
─────────────────────────
RTP payload  ≈ 1200 bytes (안전 마진 포함)

왜 중요하냐?

  TCP: 자동으로 쪼개줌 (segmentation)
  UDP: 자동 쪼개기 없음. 직접 쪼개야 함.

  MTU를 넘기면?
  → IP 레벨에서 fragmentation 발생
  → 하나라도 조각이 유실되면 전체 패킷 손실
  → 실시간에서는 치명적

  그래서 1200 바이트 기준으로 미리 쪼갬.

# 전체 파이프라인 (개념 이해용 의사 코드)

while True:
    rtmp_packet = read_rtmp()           # 1. RTMP 읽기
    media = extract_payload(rtmp_packet) # 2. payload 추출
    rtp_packets = packetize_to_rtp(media) # 3. RTP로 쪼개기
    send_to_sfu(rtp_packets)            # 4. SFU로 전달

# 1단계: RTMP 읽기

def read_rtmp():
    # TCP 소켓에서 데이터 읽음
    data = socket.recv()
    # RTMP -> FLV tag 파싱
    return parse_rtmp(data)

# 2단계: payload 추출 — "포장 뜯기"

def extract_payload(rtmp_packet):
    if rtmp_packet.type == "video":
        return rtmp_packet.h264_nal_units  # H.264 데이터
    elif rtmp_packet.type == "audio":
        return rtmp_packet.aac_frames      # AAC 데이터

# 3단계: RTP 패킷으로 쪼개기 (핵심)

def packetize_to_rtp(media):
    packets = []
    for chunk in split(media, size=1200):  # MTU 기준으로 분할
        rtp = {
            "sequence": next_seq(),     # 순서 번호
            "timestamp": current_ts(),  # 타이밍 정보
            "payload": chunk
        }
        packets.append(rtp)
    return packets

# 실제로는:
#   H.264는 FU-A 같은 fragmentation 방식 사용
#   timestamp = 프레임 단위 기준

# 4단계: SFU로 전달

def send_to_sfu(rtp_packets):
    for p in rtp_packets:
        sfu_input_queue.put(p)

Media Gateway = 포맷 변환 (RTMP → RTP)
SFU           = 분배 (RTP → 여러 클라이언트)

SFU는:
  디코딩 안 함
  인코딩 안 함
  그냥 전달 + 선택

# SFU 내부 (개념 이해용 의사 코드)

def sfu_loop():
    while True:
        packet = input_queue.get()

        for subscriber in subscribers:
            send_udp(packet, subscriber)

# 확장: 실제 SFU는 네트워크 상태에 따라 선택적 전달

def sfu_loop_adaptive():
    while True:
        packet = input_queue.get()

        for subscriber in subscribers:
            if subscriber.network_bad:
                send_low_bitrate_stream(packet, subscriber)
            else:
                send_high_bitrate_stream(packet, subscriber)

RTMP ingest 단계에서는 Media Gateway가 H.264/AAC payload를 추출해
RTP packet으로 재패키징하고, 이후 SFU가 이 RTP 스트림을 복제하여
다수의 WebRTC 클라이언트에 전달합니다.

포맷 변환과 분배는 별도의 컴포넌트로 분리되어 동작합니다.

┌──────────────┬──────────────────────┐
│ 단계         │ 역할                 │
├──────────────┼──────────────────────┤
│ Gateway      │ 포맷 변환 (RTMP→RTP) │
│ SFU          │ 분배 (복제+선택 전달) │
└──────────────┴──────────────────────┘

일반 인터넷 (Underlay):
  서울 → 미국
  = ISP가 아무 경로로 보냄
  = 우리는 제어 불가

오버레이 네트워크:
  서울 Edge → 도쿄 Edge → 미국 Edge
  = "우리가 정한 길로 보냄"
  = 경로 성능을 계속 측정하고 최적 선택

┌──────────────┬──────────────────┬──────────────────┐
│              │ Underlay (인터넷) │ Overlay (SD-RTN) │
├──────────────┼──────────────────┼──────────────────┤
│ 경로 결정    │ ISP              │ 애플리케이션      │
│ 제어         │ 없음             │ 있음              │
│ 최적화       │ 제한적           │ 실시간 가능       │
└──────────────┴──────────────────┴──────────────────┘

왜 필요하냐?
  latency 줄이려고
  packet loss 피하려고
  jitter 줄이려고

전체 RTMP → WebRTC 흐름 (최종):

RTMP (TCP)
   ↓
Media Gateway
   - H.264/AAC payload 추출
   - RTP packetize (sequence + timestamp 부여)
   ↓
SFU
   - packet 복제
   - 사용자별 선택적 분배
   ↓
오버레이 네트워크 (Edge → Edge, 최적 경로)
   ↓
WebRTC 클라이언트 (UDP)

RTMP vs WebRTC 비교:

┌──────────────┬─────────────────┬─────────────────┐
│              │ RTMP            │ WebRTC          │
├──────────────┼─────────────────┼─────────────────┤
│ 전송 프로토콜 │ TCP             │ UDP             │
├──────────────┼─────────────────┼─────────────────┤
│ 지연         │ 1~3초           │ 200ms 이하      │
├──────────────┼─────────────────┼─────────────────┤
│ 용도         │ 방송 업로드용    │ 실시간 시청용    │
│              │ (ingest)        │ (playback)      │
├──────────────┼─────────────────┼─────────────────┤
│ 오디오 코덱  │ AAC             │ Opus            │
├──────────────┼─────────────────┼─────────────────┤
│ 비디오 코덱  │ H.264           │ H.264/VP8/VP9   │
└──────────────┴─────────────────┴─────────────────┘

RTMP는 "올리는 용" (방송자 → 서버)
WebRTC는 "보는 용" (서버 → 시청자, 초저지연)

WebRTC 스트림은 RTP 기반 (Opus/VP8 등)
RTMP는 TCP 기반 (H.264/AAC)

→ 프로토콜도 다르고 코덱도 다를 수 있음
→ 서버에서 변환 과정이 필요

전체 흐름:

WebRTC Client
  ↓ RTP/UDP (Opus + VP8/H.264)
서버 (Media Gateway)
  ↓ RTP depacketization
  ↓ 디코딩 (Opus → PCM, VP8 → raw frame)
  ↓ 재인코딩 (PCM → AAC, raw frame → H.264)
  ↓ RTMP 패킷으로 재패키징
  ↓ RTMP push (TCP)
외부 CDN Ingest Endpoint
  ↓
HLS 패키징 → Edge → 시청자

핵심 포인트:

1. depacketization
   RTP 패킷에서 미디어 데이터 추출 (RTP 헤더 제거)

2. 디코딩 + 재인코딩 (트랜스코딩)
   WebRTC 코덱(Opus, VP8)과 RTMP 코덱(AAC, H.264)이
   다르기 때문에 디코딩 후 재인코딩 필요

   Opus → PCM → AAC
   VP8  → raw frame → H.264

3. 코덱이 이미 일치하면?
   WebRTC에서 H.264를 쓰고 있다면
   → 디코딩/재인코딩 없이 리패키징만 수행 가능
   → CPU 부담 대폭 감소

   H.264(RTP) → H.264(RTMP)  리패키징만
   Opus(RTP)  → AAC(RTMP)    트랜스코딩 필요

정리:

┌──────────────────┬──────────────────────────────────┐
│ 방향             │ 처리                             │
├──────────────────┼──────────────────────────────────┤
│ RTMP → WebRTC    │ FLV 파싱 → RTP 재패키징         │
│                  │ (코덱 같으면 디코딩 불필요)       │
├──────────────────┼──────────────────────────────────┤
│ WebRTC → RTMP    │ RTP depacketize → 트랜스코딩     │
│                  │ → RTMP 재패키징 → CDN push       │
│                  │ (코덱 같으면 리패키징만)          │
└──────────────────┴──────────────────────────────────┘

양방향 모두 핵심은 동일:
  코덱 일치 → 리패키징만 (가벼움)
  코덱 불일치 → 트랜스코딩 필요 (무거움)

RTC tracks (실시간 스트림)
  ↓
decode / compose (필요 시)
  ↓
encode H.264 / AAC
  ↓
package as HLS segments
  ↓
CDN cache / distribute
  ↓
브라우저에서 재생

RTMP 경유:
OBS → RTMP push → CDN ingest → HLS packaging → Edge → 재생

RTMP → WebRTC (초저지연):
OBS → RTMP push → Media Gateway → 재패키징(RTP/UDP) → WebRTC 시청

WebRTC → RTMP (CDN 배포):
WebRTC → RTP depacketize → 트랜스코딩 → RTMP push → CDN → HLS → 재생

마이크가 TTS 소리를 픽업하는 것
         |
         | 이건 물리적 현상
         | (스피커 -> 공기 -> 마이크)
         |
         v
    AEC가 처리해야 할 문제
    VAD와는 직접 관련 없음

상황         VAD 있음           VAD 없음
-------------------------------------------------
침묵 구간    무시               STT로 계속 전송
말하는 구간  감지 후 전달       구분 불가
발화 시작/끝 정확히 자름        잘림 없이 흘러감

타임라인:
00:00 ---------------------------------------- 02:00
  |                                              |
  Mic 연결됨                                 Mic 여전히 연결
  |                                              |
  v                                              v
오디오 스트림이 계속 STT로 흘러들어감
(침묵 = 무음 PCM 데이터도 "데이터"임)

Mic (연속) --> STT --> 끝없는 텍스트 조각들
                  --> LLM이 언제 응답해야 할지 모름
                  --> 중복/쓸모없는 추론 폭발

Mic ---------------------------------------------------------->
     [침묵][말][침묵][말][침묵]
      ^-- VAD 없으면 이 모든 것이 STT로 전달됨

VAD 없음:
TTS가 재생되는 동안 유저가 말하기 시작
  -> 시스템이 유저 발화 시작을 감지 못함
  -> TTS를 끊지 못함 (interruption 불가)
  -> 대화가 아니라 일방적 출력이 됨

VAD 없음 전체 흐름:
Mic -> 침묵/잡음/말 구분 불가
  -> STT  <-- 쓰레기 입력 (Garbage In)
  -> LLM  <-- 언제 응답할지 모름
  -> TTS  <-- 엉뚱한 타이밍에 말함
  -> User <-- 혼란, 끊김, barge-in 불가

STT 2가지 모드:
1. Streaming STT (실시간)   <-- Voice AI에서 사용
2. Batch STT (파일 업로드)

유저: "주문하고 싶어요"  [말 끝]

STT endpointing만 사용 (VAD 없음):
---------------------------------------------------
t=0.0s  "주문하고 싶어요" 말하기 완료
t=0.0s  유저 입장: "이제 답해줘야지"

        <-- 여기서 바로 LLM 호출했으면 좋겠음

t=0.5s  STT 내부: "아직 말 더 할 수도 있으니 대기"
t=1.0s  STT 내부: "아직 대기..."
t=1.5s  STT 내부: "침묵 1.5초 지났네 -> final 출력!"

t=1.5s  final: "주문하고 싶어요" -> LLM 호출
t=2.5s  LLM 응답 생성
t=3.0s  TTS 출력
---------------------------------------------------

유저 체감: 말 끝내고 -> 3초 후에 응답

VAD가 있으면?
---------------------------------------------------
t=0.0s  "주문하고 싶어요" 말하기 완료
t=0.3s  VAD: "발화 종료 감지!" -> 즉시 STT final 트리거
t=0.3s  LLM 호출
t=1.3s  LLM 응답
t=1.6s  TTS 출력
---------------------------------------------------

유저 체감: 말 끝내고 -> 1.6초 후 응답

케이스 A — 문장 중간 침묵

유저: "저는... [2초 침묵] ...치킨 주문할게요"

STT endpointing (VAD 없음):
---------------------------------------------------
t=0.5s  interim: "저는"
t=2.5s  침묵 2초 경과 -> STT가 final 판단!
        final: "저는"  -> LLM 호출

        LLM: "네, 무엇을 도와드릴까요?" (엉뚱한 응답)

t=3.0s  유저: "치킨 주문할게요" (계속 말하는 중)
        STT: 또 final -> LLM 또 호출
---------------------------------------------------

결과:
-> 문장이 쪼개져서 LLM이 맥락 없이 응답
-> 유저는 말 중간에 끊김 경험

케이스 B — 생각하면서 말하기

유저: "음... 그러니까... 제가 원하는 건..."

STT endpointing (VAD 없음):
-> "음" -> final -> LLM 호출
-> "그러니까" -> final -> LLM 호출
-> "제가 원하는 건" -> final -> LLM 호출

LLM은 계속 엉뚱한 응답 생성 중...

Mic -> PCM -> 전처리(AEC/AGC/NS)
                    |
                    v
              +-----+-----+
              |    VAD     |  <-- 여기서 발화 감지
              +-----+-----+
                    |
          +---------+---------+
          |                   |
     [말하는 중]          [침묵]
          |                   |
     STT로 전송          전송 안 함
          |
     STT interim/final
          |
     LLM 호출 (발화 종료 시)
          |
     TTS 응답

[Capture]
  Mic → ADC → PCM

[Real-time 통신]
  PCM → Opus → Network → Opus → PCM → Speaker

[전화]
  PCM → µ-law → Network → µ-law → PCM → Speaker

[저장/배포]
  PCM → AAC/MP3 → 저장 → 재생

[녹화 → VOD]
  RTC → decode → encode(H.264+AAC) → package(HLS) → CDN → 재생

[RTMP → HLS 배포]
  OBS → RTMP push → CDN ingest → HLS packaging → Edge → 재생

[RTMP → WebRTC 초저지연]
  OBS → RTMP push → Media Gateway → 재패키징(RTP/UDP) → WebRTC 시청

[Voice AI]
  PCM → 전처리 → VAD → STT → LLM → TTS → Speaker

1. PCM은 모든 오디오의 "기준 상태"
   → 마이크에서 나온 디지털 원본
   → 모든 처리/재생이 PCM 기준

2. 코덱은 "목적에 따라 바꿔 쓰는 것"
   → 실시간: Opus
   → 전화: µ-law
   → 저장: AAC
   → 범용: MP3

3. PCM 그대로 네트워크에 보내지 않는다
   → 768kbps vs 64kbps (10배 이상 차이)
   → 인코딩 필수

4. 실시간 통신은 UDP + RTP
   → TCP는 정확하지만 느림
   → 지연보다 정확성이 덜 중요

5. Jitter Buffer와 PLC가 품질을 지킨다
   → 네트워크 흔들림 흡수
   → 패킷 유실 보정

6. 인코딩 ≠ 트랜스코딩 ≠ 패키징
   → 인코딩: raw → 압축
   → 트랜스코딩: 압축 → 다른 압축
   → 패키징: HLS 조각으로 분할

7. SFU는 디코딩 안 하고 전달만 한다
   → packet loss 대응은 NACK/FEC/PLC로 클라이언트와 협력
   → Media Gateway = 포맷 변환, SFU = 분배

8. RTMP → WebRTC는 "프로토콜 변환"이 아니라
   → FLV tag에서 H.264/AAC 추출
   → MTU 기준으로 RTP fragmenting
   → SFU 통해 WebRTC 클라이언트로 분배

9. VAD는 Voice AI 파이프라인의 게이트키퍼
   → 4가지 역할: 침묵 필터링, 발화 종료 감지, 발화 시작 감지, barge-in
   → 에코 제거는 AEC의 역할 (물리적 현상), VAD와 별개
   → STT endpointing(1-2초)보다 VAD(0.2-0.5초)가 빠름
   → 없으면: 비용 폭증, 타이밍 불가, 문장 쪼개짐

전체 파이프라인 한 줄:
  RTMP → FLV parsing → H.264/AAC 추출 → RTP packetize (MTU 기준)
  → UDP 전송 → SFU 전달 → Client jitter buffer
  → 복구 (NACK/FEC) → 디코딩 → 재생