MCU 기반 산업용 스트리밍을 위한 오디오 코덱 분석

Xylolabs API — 코덱 실현 가능성 연구 개정일: 2026-03-22

특허 출원 중 — XAP (Xylolabs Audio Protocol) 및 XMBP (Xylolabs Metadata Binary Protocol)는 Xylolabs Inc.의 독점 기술이다. 특허 출원이 진행 중이다.

---

1. 개요

사용 사례

산업용 오디오 모니터링 시스템이다. 4채널 마이크 어레이를 96 kHz로 샘플링한다. MCU에서 실시간 압축 후 LTE-M1으로 서버에 스트리밍하고, 서버에서 디코딩하여 저장 및 분석한다.

제약 조건: LTE-M1 대역폭

LTE-M1 (LTE Cat-M1) 업링크는 양호한 환경에서 약 375 kbps이고, 현장에서는 ~100-200 kbps로 떨어진다. 프로토콜 오버헤드를 고려한 실용적인 오디오 페이로드 예산:

• 최적 조건: ~47 KB/s (375 kbps ÷ 8, 오버헤드 없음)
• 실용적 목표: ~30–40 KB/s (재전송, 헤더, 메타데이터 여유분 포함)

요구 사항

요구 사항	값
채널 수	4 (2개 스테레오 쌍)
샘플링 레이트	96 kHz
비트 심도	16비트 (24비트 선택적)
인코딩 위치	MCU (OS 없음, 베어메탈 또는 RTOS)
디코딩 위치	클라우드 서버 (Linux, 리소스 제약 없음)
최대 지속 대역폭	~40 KB/s
레이턴시 예산	종단간 < 100 ms
품질 우선순위	산업용 모니터링 — 전체 스펙트럼 보존

원시 PCM 기준선

4채널 × 96,000 샘플/초 × 16비트 = 6,144,000 비트/초 = 768 KB/s

이는 예산의 19배에 해당한다. 상당한 압축이 필요하다.

---

2. 코덱 비교표

코덱	유형	MIPS/채널 @48kHz	MIPS/채널 @96kHz	RAM/채널	압축률	품질	라이선스	MCU 실현 가능?
XAP	손실	5–10	10–20	~8 KB	10:1	우수	Xylolabs 독점 (특허 출원 중)	가능
Opus (SILK)	손실	15–25	30–50	~20 KB	10:1+	우수	BSD (무료)	한계적
Opus (CELT)	손실	30–50	60–100	~30 KB	10:1+	우수	BSD (무료)	불가
MP3 (LAME)	손실	20–40	해당없음 (최대 48 kHz)	~30 KB	10:1	양호	특허 만료 (2017년+)	한계적 @48 kHz
AAC-LC	손실	25–40	50–80	~25 KB	10:1	매우 좋음	ISO (Via Licensing)	불가 @96 kHz
HE-AAC v1	손실	30–50	60–100	~30 KB	15:1	매우 좋음	ISO (라이선스 필요)	불가
HE-AAC v2	손실	40–60	80–120	~40 KB	20:1	양호 (스테레오 전용)	ISO (라이선스 필요)	불가
xHE-AAC (USAC)	손실	50–80	해당없음	~50 KB	25:1	우수	ISO (라이선스 필요)	불가
SBC	손실	3–5	6–10	~4 KB	4–5:1	보통	Bluetooth SIG (무료)	가능
aptX	손실	5–8	10–16	~8 KB	4:1	매우 좋음	Qualcomm (라이선스 필요)	가능
aptX HD	손실	8–12	16–24	~12 KB	4:1	우수	Qualcomm (라이선스 필요)	가능 (F411/ESP32-S3)
IMA-ADPCM	손실	< 1	< 2	< 1 KB	4:1	보통	공개 도메인	가능 (모든 MCU)
Speex	손실	3–8	해당없음 (최대 32 kHz)	~4 KB	8–11:1	양호 (음성)	BSD (무료)	가능 (음성 전용)
G.722	손실	3–5	해당없음 (최대 16 kHz)	~2 KB	4:1	양호 (광대역)	ITU-T (무료)	가능 (음성 전용)
3GPP EVS	손실	10–20	15–30	~15 KB	8–12:1	우수 (음성)	3GPP (라이선스 필요)	한계적
AAC-ELD	손실	15–25	20–30	~20 KB	8–10:1	매우 좋음	ISO (라이선스 필요)	불가 @96 kHz
aptX Lossless	무손실	해당없음	해당없음	해당없음	~2:1	완벽	Qualcomm (라이선스 필요)	불가
FLAC	무손실	30–50	60–100	~50 KB	2:1	완벽	BSD (무료)	불가 (속도 부족)
ALAC	무손실	25–40	50–80	~40 KB	2:1	완벽	Apache (무료)	불가

---

3. 코덱별 상세 분석

3.1 XAP — Xylolabs Audio Protocol

• 샘플링 레이트: 8, 16, 24, 32, 44.1, 48, 96 kHz
• 프레임 크기: 7.5 ms 또는 10 ms
• 비트레이트 범위: 채널당 16–320 kbps (인코더 설정 가능)
• MCU 구현: XAP 디코더 라이브러리 — 오픈소스 참조 구현, ~5,000줄의 C 코드, 외부 의존성 없음, 고정소수점 연산 지원
• 4채널 @96 kHz 대역폭: 4 × 80 kbps = 320 kbps = 40 KB/s — LTE-M1 예산 내
• CPU 요구사항: ~10 MIPS/채널 @48 kHz, ~20 MIPS/채널 @96 kHz → 4채널 @96 kHz 총 80 MIPS → RP2350 (300 MIPS 듀얼코어) 및 ESP32-S3 (480 MIPS) 적합
• DSP 가속 시: ~7 MIPS/채널 @48 kHz, ~14 MIPS/채널 @96 kHz → Cortex-M33/M4F의 CMSIS-DSP 최적화 경로 사용 시 4채널 @96 kHz 56 MIPS (6절 참조)
• RAM: 채널당 ~8 KB 인코더 상태 → 4채널에 32 KB → 모든 대상 MCU 적합
• 레이턴시: 프레임당 7.5–10 ms 알고리즘 지연
• 품질: 64 kbps/채널에서 투명에 가까운 품질; 80 kbps/채널에서 방송급 우수한 품질
• 라이선스: Xylolabs 독점 (특허 출원 중)
• 하드웨어 가속: XAP 디코더 라이브러리는 Cortex-M33/M4F DSP 명령어(단일 사이클 MAC, 포화 연산)를 활용하는 ARM 최적화 고정소수점 경로를 포함한다. MDCT, 스펙트럼 분석, 양자화 루프는 DSP 인트린식을 통해 25–40% 속도 향상을 얻는다.

결론: 권장 — 품질, 압축 효율, CPU 예산, RAM, 라이선스 측면에서 최적의 균형. Xylolabs Rust SDK (crates/xylolabs-sdk/)에 XAP 코덱 모듈로 이미 통합됨. DSP 가속을 통해 Cortex-M33/M4F 플랫폼에서 더욱 여유 있게 동작한다.

---

3.2 Opus

• 표준: RFC 6716 (IETF)
• 모드:
• SILK: 낮은 복잡도, 음성 최적화, 최대 48 kHz
• CELT: 높은 복잡도, 풀밴드 음악, 최대 48 kHz
• 하이브리드: 12–20 ms 프레임에서 SILK + CELT 결합
• 샘플링 레이트: 8, 12, 16, 24, 48 kHz — 기본 96 kHz 미지원
• SILK 모드 CPU: ~20 MIPS/채널 → 4채널 80 MIPS → RP2350 적합, 단 48 kHz로 제한
• CELT 모드 CPU: ~40 MIPS/채널 → 4채널 160 MIPS → RP2350에서 빡빡, STM32 초과
• RAM (인코더): ~20–30 KB/채널 → 4채널에 80–120 KB — MCU에서 빡빡
• 96 kHz 제한: Opus는 내부적으로 모든 입력을 48 kHz로 리샘플링. 96 kHz 입력 인코딩은 의미 없음 — 24 kHz 이상의 고주파 콘텐츠가 폐기됨
• 품질: 48 kHz 오디오에서 최고 수준; CELT 모드 96–128 kbps/채널에서 원본과 구별 불가
• 라이선스: BSD 스타일 (무료, 특허 부담 없음)

결론: 48 kHz 스트림에 적합. 96 kHz 인코딩은 고주파 콘텐츠를 버리므로 적합하지 않음. 48 kHz로 완화할 수 있는 경우 Opus SILK가 RP2350에서 실현 가능.

---

3.3 MP3 (MPEG-1/2 Audio Layer III)

• 표준: ISO 11172-3 (MPEG-1) / ISO 13818-3 (MPEG-2)
• 최대 샘플링 레이트: 48 kHz (MPEG-1) — 96 kHz 미지원
• CPU (인코더, 예: LAME): ~30 MIPS/채널 → 4채널 @48 kHz에서 120 MIPS — 대부분 MCU에서 빡빡
• RAM: ~30 KB/채널, 상당함
• 품질: 128–192 kbps/채널에서 수용 가능; 96 kbps 이하에서 청각적 아티팩트
• 특허: 2017년까지 모든 관련 특허 만료; 완전 무료
• MCU 구현: 임베디드용 프로덕션 품질 MP3 인코더는 거의 없음; LAME은 임베디드용으로 설계되지 않음

결론: 권장하지 않음 — 96 kHz 미지원, 높은 CPU 및 RAM 요구사항, XAP 및 Opus에 의해 대체된 구식 코덱. MCU에서의 인코딩은 실용적이지 않음.

---

3.4 AAC-LC (Advanced Audio Coding — 저복잡도)

• 표준: ISO/IEC 14496-3 (MPEG-4 Audio)
• 샘플링 레이트: 최대 96 kHz 기본 지원
• CPU: ~30 MIPS/채널 @48 kHz, ~60 MIPS/채널 @96 kHz → 4채널 240 MIPS — RP2350 초과 (너무 근접), F411 및 nRF52840 대폭 초과
• RAM: ~25 KB/채널 → 4채널 100 KB
• 품질: 128 kbps에서 매우 좋음; 192 kbps에서 우수
• 라이선스: Via Licensing이 관리하는 ISO/IEC 특허 풀, 판매 단위당 로열티 필요
• MCU 인코더: Fraunhofer의 FDK-AAC가 최고의 오픈소스 인코더이지만 무거우며 베어메탈 MCU에 최적화되어 있지 않음

결론: MCU에서 권장하지 않음 — 96 kHz에서 CPU 부담이 너무 큼, 하드웨어 제품에 대한 라이선스 비용이 상당함, 검증된 MCU 인코더 라이브러리 없음.

---

3.5 HE-AAC v1 (고효율 AAC + 스펙트럼 대역 복제)

• 표준: ISO/IEC 14496-3
• 개선점: 스펙트럼 대역 복제 (SBR)는 저주파 데이터에서 고주파를 재생성하여 AAC-LC의 절반 비트레이트로 동일한 품질 제공
• CPU: SBR 분석으로 인해 AAC-LC보다 높음 — ~50 MIPS/채널 @48 kHz
• 최적 동작 범위: 48–80 kbps/채널 (절반 비트레이트로 AAC-LC @96 kbps 품질)
• 라이선스: ISO/IEC + Dolby 특허 풀, 로열티 필요
• MCU 인코더 복잡도: SBR 인코더 분석이 연산 집약적이며 일반 MCU SRAM에 맞지 않음

결론: MCU에서 실현 불가 — 인코더가 AAC-LC보다 훨씬 복잡. 서버 측 디코딩은 가능 (FFmpeg), 임베디드 하드웨어에서의 인코딩은 실용적이지 않음.

---

3.6 HE-AAC v2 (HE-AAC v1 + 파라메트릭 스테레오)

• 표준: ISO/IEC 14496-3
• 개선점: HE-AAC v1에 파라메트릭 스테레오 (PS) 추가, 스테레오를 모노 + 스티어링 파라미터로 인코딩
• CPU: AAC 변형 중 가장 높음 — ~60–80 MIPS/채널 등가
• 최적 범위: 스테레오 콘텐츠에서 24–48 kbps (음성/음악에서 높은 압축)
• 제한사항: 스테레오 (2채널) 전용 설계 — 4채널 구성에 적용 불가
• 낮은 비트레이트에서의 품질: 음성에서 매우 좋음; 낮은 비트레이트에서 스테레오 이미징 저하

결론: 실현 불가 — MCU 인코딩에 너무 복잡, 4채널 사용 사례를 배제하는 스테레오 전용 제한.

---

3.7 xHE-AAC / USAC (확장 HE-AAC / 통합 음성 및 오디오 코딩)

• 표준: ISO/IEC 23003-3 (MPEG-D)
• 기술: ACELP (음성 코딩)와 MDCT (음악 코딩)를 전환 및 고급 노이즈 쉐이핑으로 결합
• CPU: 매우 높음 — ARM Cortex-A급 프로세서용으로 설계, 마이크로컨트롤러 아님
• 품질: 현존 최고 수준. 스테레오 32 kbps에서 투명에 가까움
• 라이선스: ISO/IEC 특허 풀, 로열티 필요

결론: 어떤 MCU에서도 실현 불가 — 인코더에 OS 수준의 메모리 관리를 갖춘 풀 기능 CPU 필요. 이 사용 사례와 관련 없음.

---

3.8 SBC (서브밴드 코딩)

• 표준: Bluetooth A2DP 사양
• 알고리즘: ADPCM 유사 양자화를 갖춘 간단한 서브밴드 필터 뱅크
• CPU: 매우 낮음 — ~5 MIPS/채널, STM32F103에서도 간단
• 압축률: 4–5:1만 — XAP보다 비효율적, 동일 비트레이트에서 더 높은 대역폭 필요
• RAM: ~4 KB/채널, 우수
• 품질: Bluetooth 스피커에 적합; 고품질 보관 또는 스펙트럼 분석에는 부적합
• 라이선스: Bluetooth SIG 조건 하에 무료

결론: 실현 가능하지만 단순성을 제외한 모든 차원에서 XAP에 비해 열등. SBC는 XAP가 존재하기 전에 최소 공통 분모 코덱으로 설계됨. XAP를 사용할 수 있을 때는 XAP를 사용하고; XAP 통합이 불가능한 최후 수단으로만 SBC 사용.

---

3.9 aptX / aptX HD

• 표준: Qualcomm 독점
• 알고리즘: 향상된 서브밴드 처리를 갖춘 ADPCM
• aptX CPU: ~8 MIPS/채널 → 4채널 32 MIPS — 실현 가능
• aptX HD CPU: ~12 MIPS/채널 → 4채널 48 MIPS — 대부분 MCU에서 실현 가능
• 압축률: 4:1 (ADPCM과 동일 비율이지만 지각적 품질 현저히 우수)
• aptX 품질: 매우 좋음 — 16비트 CD 품질과 유사
• aptX HD 품질: 인간 지각에서 거의 무손실; 24비트 입력 지원
• RAM: ~8–12 KB/채널, 관리 가능
• 라이선스: Qualcomm 라이선스 계약 필요 — Qualcomm 실리콘 없는 커스텀 하드웨어에서는 비용 과다, SDK 접근 제한

결론: 품질은 좋지만 라이선스 실용성 없음. Qualcomm의 라이선스 모델이 aptX를 상업적으로 그들의 칩셋에 묶음. 오픈 커스텀 하드웨어 개발에 적합하지 않음.

---

3.10 IMA-ADPCM (대화형 멀티미디어 협회 적응형 차분 PCM)

• 표준: IMA/DVI ADPCM 사양
• 알고리즘: 적응형 스텝 크기를 갖춘 4비트 양자기로 샘플 간 차이를 인코딩
• CPU: 무시할 수준 — < 1 MIPS/채널 → 4채널 @96 kHz에서 < 4 MIPS
• 압축률: 고정 4:1 (16비트 입력 → 4비트 출력)
• RAM: < 1 KB/채널, 어떤 MCU에도 적합
• 품질: 보통, 청각적 양자화 노이즈, 고주파 아티팩트, 심리음향 모델링 없음
• 4채널 @96 kHz 대역폭: 768 KB/s ÷ 4 = 192 KB/s — LTE-M1 예산 초과
• 4채널 @48 kHz 대역폭: 384 KB/s ÷ 4 = 96 KB/s — 여전히 예산 초과
• 라이선스: 공개 도메인

결론: 기준 폴백 — 연산적으로 항상 실현 가능, 어떤 MCU에서도 동작. 그러나 4:1 압축은 LTE-M1을 통한 96 kHz / 4채널 사용 사례에 충분하지 않음. 샘플링 레이트를 추가로 줄인 경우에만 실용적 (예: 음성 전용 모니터링을 위한 2채널 @24 kHz).

---

3.11 Speex

• 표준: Xiph.Org 오픈 사양 (RFC 5574)
• 알고리즘: CELP (Code-Excited Linear Prediction)
• 최대 샘플링 레이트: 32 kHz (초광대역) — 48 kHz 또는 96 kHz 미지원
• 비트레이트: 2.15–44.2 kbps (가변, 모드 의존)
• CPU: ~3–8 MIPS/채널 (협대역~초광대역)
• RAM: ~4 KB/채널
• 품질: 음성에 적합; G.722에 없는 노이즈 억제, 에코 제거, VAD(음성 활동 감지) 기능 포함
• 라이선스: BSD — 완전 무료, 특허 부담 없음
• 비고: Speex 프로젝트는 공식적으로 신규 배포에 Opus를 후속 코덱으로 권장한다. 그러나 Opus가 너무 무겁고(>30 MIPS/채널) G.722의 16 kHz 한계가 제한적인 MCU 음성 전용 사용 사례에서는 Speex가 여전히 유효한 선택이다.

결론: 음성 전용 대안 — G.722보다 높은 압축률(8–11:1 vs 4:1)과 내장 노이즈 억제로 8–32 kHz 음성 모니터링에 적합. 일반 오디오에서는 Opus가 대체; 광대역 산업용 오디오에는 XAP가 권장 사항으로 유지.

---

3.12 G.722

• 표준: ITU-T G.722
• 알고리즘: 2개 서브밴드를 갖춘 서브밴드 ADPCM
• 최대 샘플링 레이트: 16 kHz (광대역 음성) — 48 kHz 또는 96 kHz 미지원
• CPU: ~5 MIPS/채널
• 품질: 음성에 적합; 풀밴드 오디오에는 전혀 부적합
• 라이선스: ITU-T — 무료

결론: 음성 전용 — 애플리케이션이 협대역 음성 모니터링인 경우에만 유용. 96 kHz 산업용 오디오에는 적용 불가.

---

3.13 FLAC (무손실 오디오 코덱)

• 표준: Xiph.Org 오픈 사양
• 알고리즘: 선형 예측 코딩 + Rice 엔트로피 코딩
• CPU: ~60–100 MIPS/채널 @96 kHz → 4채널 ~400 MIPS — 모든 대상 MCU 대폭 초과
• 압축률: ~2:1 (무손실, 콘텐츠 의존)
• RAM: ~50 KB/채널, 상당함
• 4채널 @96 kHz 대역폭: ~384 KB/s — LTE-M1 예산의 10배 초과
• 품질: 완벽, 수학적으로 무손실

결론: 실현 불가 — CPU 비용과 결과 대역폭 모두 제약을 초과. FLAC은 서버 측 스토리지 트랜스코딩에 탁월하지만 이 임베디드 사용 사례에서 인코딩 코덱이 아님.

---

3.14 ALAC (Apple 무손실 오디오 코덱)

• 표준: Apple 오픈소스, Apache 2.0 라이선스
• 알고리즘: FLAC과 유사; 정수 다항식 예측기 + Rice 코딩
• CPU: ~50–80 MIPS/채널 @96 kHz → 4채널 ~320 MIPS — 대부분 MCU 초과
• RAM: ~40 KB/채널
• 품질: 완벽 (무손실)
• 라이선스: Apache 2.0 (무료)

결론: 실현 불가 — FLAC과 동일한 제약. 이 사용 사례에서 FLAC 대비 이점 없음, Linux 서버에서 툴링 지원도 적음.

---

3.15 3GPP EVS (Enhanced Voice Services)

• 표준: 3GPP TS 26.441 (Release 12+)
• 샘플링 레이트: 8, 16, 32, 48 kHz — 기본 96 kHz 미지원
• 비트레이트: 5.9–128 kbps (모드 의존)
• CPU: ~15–30 MIPS/채널 — 중간 복잡도
• RAM: ~15 KB/채널
• 품질: 음성에서 우수 — 초광대역 지원을 갖춘 현존 최고 수준의 음성 코덱
• 라이선스: 3GPP 특허 풀 — 단위당 로열티 필요, 복잡한 라이선스 조건
• MCU 실현 가능성: RP2350에서 4채널 @48 kHz (~120 MIPS)는 한계적이나, 96 kHz 미지원으로 고려 대상에서 제외

결론: 권장하지 않음 — 우수한 음성 코덱이나 최대 48 kHz로 제한되며, 3GPP 라이선스가 필요하고, 96 kHz 산업용 광대역 오디오 모니터링에서 XAP 대비 이점이 없다.

---

3.16 AAC-ELD (Advanced Audio Coding — 향상된 저지연)

• 표준: ISO/IEC 14496-3 (MPEG-4 Audio, 저지연 프로파일)
• 알고리즘: 저지연 MDCT 윈도우와 선택적 SBR을 갖춘 AAC-LC 코어
• CPU: ~20–30 MIPS/채널 @96 kHz — AAC-LC보다 낮은 지연이나 유사한 연산 비용
• RAM: ~20 KB/채널
• 레이턴시: ~15–30 ms (표준 AAC-LC보다 현저히 낮음)
• 품질: 매우 좋음 — 실시간 통신용으로 설계됨 (FaceTime, VoLTE)
• 라이선스: ISO/IEC 특허 풀 — 로열티 필요

결론: MCU @96 kHz에서 실현 불가 — 4채널 @96 kHz에 ~80–120 MIPS 필요, RP2350에서 빡빡하며 대부분 단일코어 MCU를 초과한다. 라이선스 비용 및 MCU 최적화 인코더 부재로 비실용적. XAP가 더 낮은 복잡도로 유사한 저지연 목표를 달성한다.

---

3.17 aptX Lossless

• 표준: Qualcomm 독점 (Snapdragon Sound)
• 알고리즘: 적응형 무손실/손실 하이브리드 — 무손실 시 ~1 Mbps, 손실 폴백 시 ~300 kbps
• 대역폭: 무손실 모드에서 ~1 Mbps — LTE-M1 예산을 대폭 초과
• CPU: 높음 — Qualcomm 애플리케이션 프로세서용으로 설계, MCU 아님
• 라이선스: Qualcomm 독점 — Qualcomm 실리콘 생태계로 제한

결론: 실현 불가 — 대역폭 요구사항 (~1 Mbps)이 LTE-M1 용량의 20배, Qualcomm 실리콘 필요, MCU 구현 없음. 무손실이 필요한 경우 SD 카드에 녹음 후 일괄 업로드.

---

4. 대역폭 분석표

코덱	설정	비트레이트	KB/s	LTE-M1 적합?	품질
원시 PCM 16비트	4채널 @96 kHz	6144 kbps	768 KB/s	불가	완벽
원시 PCM 16비트	4채널 @48 kHz	3072 kbps	384 KB/s	불가	완벽
FLAC	4채널 @96 kHz	~3072 kbps	~384 KB/s	불가	무손실
FLAC	4채널 @48 kHz	~1536 kbps	~192 KB/s	불가	무손실
IMA-ADPCM	4채널 @96 kHz	1536 kbps	192 KB/s	불가	보통
IMA-ADPCM	4채널 @48 kHz	768 kbps	96 KB/s	불가 (2배 초과)	보통
aptX	4채널 @96 kHz	1536 kbps	192 KB/s	불가	매우 좋음
aptX	4채널 @48 kHz	768 kbps	96 KB/s	불가	매우 좋음
SBC	4채널 @48 kHz	~600 kbps	~77 KB/s	불가	보통
MP3 @128k	4채널 @48 kHz	512 kbps	64 KB/s	가능 (한계적)	양호
AAC-LC @128k	4채널 @96 kHz	512 kbps	64 KB/s	가능 (한계적)	매우 좋음
Opus SILK @64k	4채널 @48 kHz	256 kbps	32 KB/s	가능	우수
XAP @80k	4채널 @96 kHz	320 kbps	40 KB/s	가능	우수
XAP @64k	4채널 @96 kHz	256 kbps	32 KB/s	가능	매우 좋음
HE-AAC @48k	4채널 @48 kHz	192 kbps	24 KB/s	가능	매우 좋음
Speex @20k	4채널 @32 kHz	80 kbps	10 KB/s	가능	양호 (음성)

핵심 발견: XAP @80 kbps/채널은 96 kHz 지원, LTE-M1 대역폭 적합, 대상 MCU 실행을 동시에 달성하는 유일한 코덱이다.

---

5. MCU 플랫폼 실현 가능성 매트릭스

CPU 예산은 최악 단일 코어 활용을 가정한다. 듀얼코어 MCU (RP2350, ESP32-S3)는 인코더 작업을 코어 간 분배할 수 있다.

코덱 / 설정	RP2350 (300 MIPS, 520 KB SRAM)	STM32F103 (72 MIPS, 20 KB)	STM32F411 (100 MIPS, 128 KB)	ESP32-S3 (480 MIPS, 512 KB+PSRAM)	nRF52840 (64 MIPS, 256 KB)
XAP 4채널 @96 kHz (80 MIPS, 32 KB)	가능	불가 (RAM)	한계적	가능	불가
XAP 4채널 @48 kHz (40 MIPS, 32 KB)	가능	불가 (RAM)	가능	가능	한계적
XAP 2채널 @48 kHz (20 MIPS, 16 KB)	가능	가능	가능	가능	가능
Opus SILK 4채널 @48 kHz (80 MIPS, 80 KB)	가능	불가	한계적	가능	불가
SBC 4채널 @48 kHz (20 MIPS, 16 KB)	가능	불가 (RAM)	가능	가능	한계적
IMA-ADPCM 4채널 @96 kHz (< 8 MIPS, 4 KB)	가능	가능	가능	가능	가능
FLAC 4채널 @96 kHz (~400 MIPS, 200 KB)	불가	불가	불가	한계적	불가
AAC-LC 4채널 @96 kHz (240 MIPS, 100 KB)	불가	불가	불가	한계적	불가

참고 사항

• RP2350: 각 150 MHz의 Cortex-M33 듀얼 코어; 총 300 MIPS. 각 코어는 ARMv8-M DSP 확장 포함: 단일 사이클 32x32→64 MAC (SMLAL), 듀얼 16x16 MAC (SMLAD/SMUAD), 포화 연산 (QADD/QSUB/SSAT), 비트 필드 추출 (SBFX/UBFX). 이 DSP 명령어들은 XAP의 MDCT, 스펙트럼 쉐이핑, FIR 다운샘플링을 25–40% 가속한다. DSP 최적화 XAP를 사용하면 4채널 @96 kHz가 ~80 MIPS에서 ~56 MIPS로 줄어들어 단일 코어에서 충분한 여유가 생긴다.
• STM32F103: 72 MHz Cortex-M3, SRAM 20 KB. DSP 확장 없음, FPU 없음. 4채널 XAP의 32 KB 인코더 상태조차 가용 RAM을 초과한다. 최대: 2채널 XAP @48 kHz (16 KB 상태), 또는 IMA-ADPCM (무시할 CPU, < 1 KB 상태).
• STM32F411: 단정밀도 FPU AND 완전한 DSP 확장을 갖춘 100 MHz Cortex-M4F. FPU는 XAP 부동소수점 경로를 가속하고, DSP 명령어(M33과 동일하며 하드웨어 정수 나눗셈 추가)는 고정소수점 경로를 가속한다. DSP 최적화 XAP를 사용하면 4채널 @96 kHz는 ~56 MIPS — CPU 활용률 56%로 실현 가능하며, 기준 80% 추정치 대비 현저한 개선이다. CMSIS-DSP 라이브러리는 최적화된 FFT 및 FIR 루틴을 드롭인 형태로 포함한다.
• ESP32-S3: 240 MHz Xtensa LX7 듀얼 코어 (총 480 MIPS) + 8 MB PSRAM. Processor Instruction Extensions (PIE)를 통한 128비트 SIMD 지원 — 단일 명령으로 4x f32 또는 8x i16 병렬 처리 가능. PIE는 FFT/MDCT 배치 연산에서 2–4배 속도 향상을 달성한다. 하드웨어 AES/SHA 가속기가 TLS 오버헤드를 오프로드한다. 성능이 가장 높은 플랫폼으로, SIMD 사용 시 Opus CELT 2채널 또는 XAP 4채널 @96 kHz를 CPU 활용률 20% 미만으로 실행 가능.
• nRF52840: 64 MHz Cortex-M4F, FPU 및 DSP 확장 포함. RAM (256 KB)은 충분하지만 CPU가 제한적. DSP 최적화 시 XAP 2채널 @48 kHz는 ~14 MIPS (활용률 22%) — 여유 있음. XAP 4채널 @48 kHz (~28 MIPS, 44%)는 DSP 가속으로 실현 가능하지만 빡빡하다.

CMSIS-DSP 통합

ARM의 CMSIS-DSP 라이브러리는 모든 Cortex-M 코어를 위한 하드웨어 최적화 DSP 루틴을 포함한다. XAP 인코더에서 사용하는 주요 함수:

CMSIS-DSP 함수	용도	C 대비 속도 향상
arm_rfft_fast_f32	MDCT/스펙트럼 분석	3–5배
arm_fir_f32 / arm_fir_q15	FIR 다운샘플링 필터	2–4배
arm_dot_prod_f32	양자화 내적 연산	2–3배
arm_scale_f32	이득 정규화	2배
arm_fill_f32 / arm_copy_f32	버퍼 관리	1.5–2배

Xylolabs SDK는 빌드 설정에서 XYLOLABS_USE_CMSIS_DSP=1을 설정하면 Cortex-M 대상에서 CMSIS-DSP를 자동으로 링크한다.

---

6. DSP 및 하드웨어 가속

각 대상 MCU의 하드웨어 기능이 코덱 CPU 비용을 기준 MIPS 추정치 아래로 낮춘다. 이는 이론적 수치가 아닌 실리콘 자체의 명령어 수준 실제 속도 향상을 반영한다.

Cortex-M33 DSP 확장 (RP2350, nRF9160)

ARMv8-M Cortex-M33은 다음을 포함하는 필수 DSP 확장을 포함한다:

• 단일 사이클 32x32→64 MAC (SMLAL, UMLAL) — FIR 필터 및 MDCT 누산의 핵심
• 듀얼 16x16→32 MAC (SMLAD, SMUAD) — 사이클당 두 개의 16비트 샘플 쌍 처리, 16비트 오디오 경로에서 처리량 2배
• 포화 연산 (QADD, QSUB, SSAT, USAT) — ADPCM 스텝 크기 적응 및 XAP 양자화에서 분기 기반 클리핑 제거
• 비트 필드 추출 (SBFX, UBFX) — XMBP 바이너리 프로토콜 파싱을 위한 효율적인 언패킹

코덱에 대한 영향:

코덱	기준 MIPS/채널 @96 kHz	DSP 적용 시	감소율
XAP	~20	~14	-30%
IMA-ADPCM	< 2	< 1	-50%
SBC	~10	~7	-30%

Cortex-M4F FPU + DSP (STM32F411, STM32WB55, nRF52840)

M33 DSP 확장의 모든 기능에 더해:

• 단정밀도 FPU — 소프트웨어 에뮬레이션의 10–20 사이클 대비 1–3 사이클 하드웨어 부동소수점 곱셈-누산
• 하드웨어 정수 나눗셈 (SDIV, UDIV) — 소프트웨어 나눗셈의 20–100 사이클 대비 2–12 사이클
• FPU 영향: XAP는 고정소수점과 부동소수점 인코더 경로 모두 제공. M4F에서는 FPU가 정규화, 스케일링, 스펙트럼 분석을 네이티브로 처리하므로 부동소수점 경로가 고정소수점 경로보다 더 빠를 수 있음

코덱에 대한 영향:

코덱	기준 MIPS/채널 @96 kHz	FPU+DSP 적용 시	감소율
XAP (부동소수점 경로)	~20	~12	-40%
XAP (고정소수점 경로)	~20	~14	-30%
Opus SILK	~50	~35	-30%

ESP32-S3 벡터 확장 (PIE)

Xtensa LX7 코어는 Processor Instruction Extensions (PIE)를 포함한다:

• 128비트 SIMD — 단일 명령으로 4x f32 또는 8x i16 처리
• 전용 벡터 레지스터 — 병렬 DSP 파이프라인용 16개 × 128비트 레지스터
• 하드웨어 AES/SHA — TLS 핸드셰이크 및 암호화를 CPU에서 오프로드, 코덱 작업에 사이클 확보
• PSRAM DMA — 대용량 오디오 버퍼를 PSRAM에 두고 처리를 위해 내부 SRAM으로 DMA 전송

코덱에 대한 영향:

코덱	기준 MIPS/채널 @96 kHz	PIE SIMD 적용 시	감소율
XAP	~20	~8	-60%
Opus CELT	~100	~50	-50%
FLAC	~100	~60	-40%

ESP32-S3는 PIE를 통해 다른 플랫폼에서 실현 불가능한 코덱도 실행할 수 있다 — Opus CELT 2채널 @48 kHz, 심지어 실험적 무손실 캡처를 위한 FLAC 2채널 @48 kHz도 가능하다.

Rust SDK DSP 피처 플래그

Rust SDK (crates/xylolabs-sdk/)는 Cargo 피처 플래그를 통해 DSP 가속을 지원한다:

피처	타겟	효과
cmsis-dsp	Cortex-M33 (RP2350, nRF9160), Cortex-M4F (STM32F411, nRF52840)	CMSIS-DSP 최적화 MDCT 및 FIR 경로 활성화
esp32-simd	ESP32-S3 (Xtensa LX7)	PIE SIMD 최적화 MDCT 경로 활성화

# Cargo.toml -- RP2350용 DSP 가속 활성화
[dependencies]
xylolabs-sdk = { path = "../../crates/xylolabs-sdk", features = ["xap", "cmsis-dsp"] }

# Cargo.toml -- ESP32-S3용 SIMD 가속 활성화
xylolabs-sdk = { path = "../../crates/xylolabs-sdk", features = ["xap", "esp32-simd"] }

C SDK의 경우 빌드 설정에서 XYLOLABS_USE_CMSIS_DSP=1 또는 XYLOLABS_USE_ESP32S3_SIMD=1을 설정한다 (명시적으로 설정하지 않으면 컴파일러 플래그에서 자동 감지).

타겟별 CPU 예산 및 DSP 최적화 상세 내용은 성능 프로파일을 참고한다.

실용적 권장 사항

1. Cortex-M 대상에서 항상 CMSIS-DSP를 활성화한다: Rust SDK features = ["cmsis-dsp"], C SDK XYLOLABS_USE_CMSIS_DSP=1. 최적화된 FFT 및 FIR 루틴은 코드 변경 없이 드롭인 교체가 가능하다.
2. Cortex-M4F 대상 (STM32F411)에서 XAP 부동소수점 경로를 사용한다. FPU 덕분에 부동소수점 변환 오버헤드에도 불구하고 고정소수점 경로보다 빠르다.
3. Cortex-M33 대상 (RP2350)에서 XAP 고정소수점 경로를 사용한다. FPU가 없기 때문이다. DSP 확장은 여전히 MAC 집약적 연산에서 유의미한 속도 향상을 달성한다.
4. ESP32-S3 빌드에서 PIE 인트린식을 활성화한다: Rust SDK features = ["esp32-simd"], C SDK XYLOLABS_USE_ESP32S3_SIMD=1. ESP-IDF 컴파일러는 일부 루프를 자동 벡터화하지만, XAP 핫 경로에서 명시적 PIE 인트린식을 사용하면 추가로 20–30% 성능 향상을 얻을 수 있다.

---

7. 권장 사항

주 선택: XAP @64–80 kbps/채널

XAP는 모든 평가 차원에서 이 사용 사례에 최적인 코덱이다:

기준	XAP 결과
기본 96 kHz 지원	있음
4채널 @96 kHz LTE-M1 적합 (@80k)	40 KB/s — 가능
4채널 @96 kHz CPU	80 MIPS — RP2350, ESP32-S3 적합
4채널 RAM	32 KB — 모든 대상 MCU 적합
라이선스	Xylolabs 독점 (특허 출원 중)
레이턴시	7.5–10 ms 프레임 — 저지연
SDK 통합	Rust SDK (crates/xylolabs-sdk/)의 XAP 코덱 모듈

권장 동작 지점: - 비트레이트: 최고 품질을 위해 80 kbps/채널; 품질 손실 허용 가능한 대역폭 절약을 위해 64 kbps/채널 - 프레임 크기: 10 ms (7.5 ms보다 낮은 CPU, 허용 가능한 레이턴시) - 총 스트림: 4 × 80 kbps = 320 kbps = 40 KB/s

폴백: IMA-ADPCM

XAP 통합이 불가능한 경우 (리소스 제약 플랫폼, STM32F103, 4채널의 nRF52840):

• CPU: 무시할 수준 (< 1 MIPS/채널)
• RAM: < 1 KB/채널
• 트레이드오프: 4:1 압축만 — LTE-M1에 맞추기 위해 채널 수 또는 샘플링 레이트 감소 필요
• 2채널 @24 kHz ADPCM = 192 kbps = 24 KB/s — 예산 내

48 kHz 전용 사용의 경우: Opus SILK

48 kHz 샘플링 레이트를 허용하고 최대 코덱 품질이 필요한 경우:

• 8–48 kHz 오디오에서 최고 수준의 품질
• 풍부한 서버 측 생태계 (FFmpeg, libopus, 웹 브라우저 기본 지원)
• BSD 라이선스, 무료
• SILK 모드: 4채널 @48 kHz에서 80 MIPS — RP2350 및 ESP32-S3 적합

---

8. 서버 측 디코드 지원 매트릭스

코덱	FFmpeg 지원	디코드 라이브러리	저장 형식	비고
XAP	지원 (XAP 디코더 라이브러리, FFmpeg 7.1+)	XAP 디코더 라이브러리 (C, Apache 2.0)	FLAC/WAV로 트랜스코딩	XAP 디코더 지원으로 빌드; 7.5/10 ms 프레임 + HR 모드 (48/96 kHz) 지원
Opus	지원 (libopus)	FFmpeg 기본	직접 웹 재생	현대 플랫폼에서 가장 잘 지원되는 코덱
MP3	지원 (libmp3lame)	FFmpeg 기본	직접 웹 재생	성숙하고 범용 지원
AAC-LC	지원 (libfdk_aac)	FFmpeg 기본	직접 웹 재생	fdk-aac GPL 문제 — non-free FFmpeg 빌드 필요
HE-AAC	지원 (libfdk_aac)	FFmpeg 기본	직접 웹 재생	fdk-aac 요구사항 동일
SBC	지원 (내장)	FFmpeg 기본	AAC/Opus로 트랜스코딩 필요	낮은 품질 — 저장을 위한 트랜스코딩
Speex	지원 (libspeex)	libspeex (C, BSD)	Opus/WAV로 트랜스코딩	FFmpeg에서 --enable-libspeex로 빌드; 음성 전용, 최대 32 kHz
IMA-ADPCM	지원 (adpcm_ima_wav)	FFmpeg 기본	WAV 컨테이너	간단한 디코딩, 모든 FFmpeg 빌드에 내장
FLAC	지원 (내장)	FFmpeg 기본	직접 무손실 저장	표준 보관 형식

XAP 서버 통합

권장 방식: 서버 측 XAP 디코딩에는 XAP 디코더 라이브러리를 사용한다. 여기 표시된 C API는 프로그래밍 방식 제어가 필요한 경우의 대안이다.

XAP 디코더 라이브러리를 직접 링크하여 더 낮은 수준의 제어를 할 수 있다:

// Rust - 권장
// xap 크레이트(XAP 디코더 라이브러리 바인딩)를 사용한 서버 측 XAP 디코드
use xap::{Decoder, PcmFormat};

let mut decoder = Decoder::new(frame_us, sample_rate);
let pcm_output = decoder.decode::<i16>(xap_frame).unwrap();

Legacy C equivalent

// 서버 측 XAP 디코드 (C 예시)
#include "xap.h"

xap_decoder_t decoder = xap_setup_decoder(frame_us, sample_rate, 0, mem);
xap_decode(decoder, xap_frame, xap_frame_len, XAP_PCM_FORMAT_S16,
           pcm_output, stride);

디코딩 후, 보관을 위해 FLAC 또는 WAV에 쓰거나 웹 전달을 위해 Opus로 트랜스코딩한다.

---

9. 구현 로드맵

현재 상태

1. Rust SDK (crates/xylolabs-sdk/)가 XAP 코덱 모듈을 포함한 권장 구현체이다
2. 레거시 C SDK (sdk/c/common/src/xap_encoder.c)는 사용 가능하나 폐기 예정이다
3. IMA-ADPCM 인코더가 폴백으로 사용 가능하다
4. E2E 번인 테스트로 XAP 인코딩 안정성 검증 완료 (4개 시나리오, 10대 동시 접속, QEMU ARM 에뮬레이션)
5. 서버 측 XAP 디코더 통합 대기 중이다

계획된 단계

단계	작업	우선순위
1	Axum 인제스트 서버에 XAP 디코더 라이브러리 통합	높음
2	XAP 프레임용 XMBP 청크 타입 정의 (코덱 ID, 비트레이트, frame_us 필드)	높음
3	보관 저장을 위한 XAP → FLAC 트랜스코드 파이프라인 구현	높음
4	ESP32-S3 SDK 대상에 Opus 인코더 추가 (충분한 CPU)	중간
5	Rust SDK 전환에 따른 레거시 C SDK (sdk/c/) 폐기	중간

코덱 ID 할당 (XMBP 프로토콜)

코덱 ID	코덱	비고
0x01	원시 PCM S16LE	디버그/개발 전용
0x02	IMA-ADPCM	폴백 기준선
0x03	XAP	주요 프로덕션 코덱
0x04	Opus	ESP32-S3 / 고 CPU 플랫폼
0x05	Speex	음성 전용 (최대 32 kHz)

---

참고 자료

• RFC 6716 (Opus): https://www.rfc-editor.org/rfc/rfc6716
• IMA ADPCM: IMA Digital Audio Focus and Technical Working Group, 1992
• LTE-M1 (LTE Cat-M1) 사양: 3GPP TS 36.300, Release 13