Chapter 10

블루투스 오디오

무선 이어폰으로 영상을 보면 입 모양과 소리가 살짝 어긋난다. 게임에서는 총소리가 늦게 들린다. 사람 많은 지하철역에서는 음악이 툭툭 끊기고, 통화할 때는 상대 목소리가 갑자기 먹먹해진다. 모두 블루투스 오디오가 제시간에 도착해야 하는 데이터를 다룬다는 데서 생기는 일이다. 이 장에서는 20년 넘게 쓰인 클래식 오디오가 어떻게 동작하는지, 소리가 어디서 늦어지는지 계산해 보고, 5.2에서 시작된 LE 오디오가 등시성 채널로 무엇을 바꿨는지 따라간다. 그리고 한 송신기가 수많은 이어폰에 소리를 뿌리는 Auracast까지 간다.

음악(A2DP)과 통화(HFP)가 클래식에서 서로 다른 길(ACL, SCO/eSCO)을 쓰는 이유를 안다.
코덱별 비트레이트가 무선 링크의 여유와 공중 점유 시간에 어떤 부담을 주는지 계산한다.
프레임 길이, 전송, 재전송 여유, 지터 버퍼, 디코딩으로 이루어진 지연 예산을 쌓아 본다.
LE 등시성 채널(CIS·BIS)의 ISO_Interval, NSE, BN, FT 같은 파라미터가 신뢰도와 지연을 어떻게 맞바꾸는지 시뮬레이터로 확인한다.
Auracast 브로드캐스트가 주기적 광고와 BIG 위에서 동작하는 방식을 이해한다.

클래식 오디오: 음악은 ACL로, 통화는 SCO로

무선 이어폰은 사실 여러 프로파일의 묶음이다. 프로파일은 1장에서 본 대로 Core 밖의 사양이다.

A2DP(Advanced Audio Distribution Profile): 음악. 압축된 오디오를 클래식 ACL 링크 위의 L2CAP 채널로 보낸다. 일반 데이터처럼 확인 응답과 재전송이 있어 소리가 정확히 도착하지만, 늦게 도착할 수 있다. 그래서 받는 쪽은 수백 ms의 버퍼를 두고 재생한다.
AVRCP: 재생·정지·다음 곡, 볼륨 같은 리모컨 명령.
HFP(Hands-Free Profile): 통화. 양방향 음성을 SCO(Synchronous Connection-Oriented) 또는 1.2에서 추가된 eSCO 링크로 보낸다. 정해진 슬롯을 미리 예약해 두고 늦지 않게 보낸다.

SCO는 실시간성의 극단이다. 예를 들어 HV3 패킷은 30바이트를 6슬롯(3.75 ms)마다 보내 64 kb/s를 만든다. 재전송도 CRC도 없다. 깨지면 그 조각만 잡음으로 들리고 지나간다. 음성은 늦게 오는 것보다 조금 깨지는 편이 낫기 때문이다. eSCO는 예약 슬롯 뒤에 재전송 창을 두어 한두 번은 다시 보낼 수 있게 했다. 코덱은 처음에는 8 kHz 표본화의 CVSD(협대역, 유선 전화 음질), 이후 HFP가 16 kHz의 mSBC(광대역), 최근에는 LC3를 쓰는 초광대역으로 발전했다. 음악을 듣다 전화가 오면 소리가 먹먹해지는 것은 A2DP의 수백 kb/s에서 이 좁은 음성 링크로 바뀌기 때문이다.

SCO/eSCO 논리 전송과 HV·EV 패킷(HV3 30바이트, 재전송 없음): [Vol 2] Part B §6.5.2·§6.5.3 · CVSD 코덱: [Vol 2] Part B §9 · 1.2의 새 기능 eSCO: [Vol 1] Part C §2.1 · A2DP·AVRCP·HFP: Core 밖의 프로파일 사양

왼쪽 귀와 오른쪽 귀는 어떻게 받을까

클래식 A2DP는 휴대폰 한 대와 수신기 한 대 사이의 링크다. 완전 무선(TWS) 이어폰이 처음 나왔을 때는 휴대폰이 한쪽 이어폰에 스테레오를 보내고, 그 이어폰이 다른 쪽으로 다시 중계했다. 머리 하나를 사이에 두고 2.4 GHz를 넘기는 일은 2장의 “몸 손실” 때문에 쉽지 않고, 중계 이어폰의 배터리가 먼저 닳았다. 이후 제조사들은 다른 쪽 이어폰이 휴대폰의 신호를 옆에서 같이 듣는 방식(각 회사의 독자 기술)을 썼다. LE 오디오는 이것을 표준으로 해결했다. 휴대폰이 귀마다 따로 등시성 스트림을 보내고, 두 스트림을 같은 시각에 재생하도록 묶는다(아래 CIG).

코덱과 비트레이트: 얼마나 보내야 하나

CD 음질(44.1 kHz, 16비트, 스테레오)은 1,411 kb/s다. 3장에서 본 것처럼 클래식의 실제 처리량 상한은 약 2 Mb/s이고, 그마저도 Wi-Fi와 나눠 쓰며 재전송 여유를 남겨야 한다. 그래서 오디오는 반드시 압축해 보낸다. 압축 방식이 코덱(codec)이다.

코덱	쓰는 곳	대표 비트레이트	비고
SBC	A2DP 필수	~ 200 ~ 345 kb/s	단순·저지연 연산, 모든 기기가 지원
AAC	A2DP 선택	~ 128 ~ 256 kb/s	같은 비트레이트에서 SBC보다 효율적
aptX / aptX HD	A2DP (회사 코덱)	352 ~ 384 / 576 kb/s	고정 비트레이트
LDAC	A2DP (회사 코덱)	330 / 660 / 990 kb/s	연결 상태에 따라 바꾼다
CVSD / mSBC	HFP 통화	64 kb/s	8 kHz 협대역 / 16 kHz 광대역
LC3	LE 오디오 필수	예: 16 kHz 32 kb/s ~ 48 kHz 124 kb/s (채널당)	7.5 ms·10 ms 프레임, 낮은 비트레이트에서 강함

코덱과 그 설정은 Core 밖의 사양(A2DP, HFP, LC3, BAP)과 각 회사 문서에 있다. 비트레이트는 대표적인 설정값이다.

비트레이트가 높으면 음질에 유리하지만 무선의 짐이 커진다. 같은 데이터를 보내는 데 공중을 더 오래 차지하므로 Wi-Fi와 부딪힐 기회가 늘고, 패킷이 깨졌을 때 다시 보낼 시간 여유가 줄어든다. 사람 많은 곳에서 고음질 코덱이 먼저 끊기는 이유다.

SIMULATOR

코덱 비트레이트와 링크 여유: 어디서부터 끊기나

코덱

패킷 손실률 (간섭·거리) 링크가 실제로 낼 수 있는 처리량

필요한 공중 시간 비율—

재전송 여유—

판정—

막대: 링크 용량(전체)에서 코덱 데이터가 차지하는 몫, 손실을 메우기 위한 재전송 몫, 남는 여유. 손실률 p에서 평균 전송 횟수는 1/(1−p)이므로 필요한 공중 시간은 비트레이트 ÷ (1−p)다. 해볼 것: ① 손실률을 10% → 40%로 올려 보자. LDAC 990은 금방 용량을 넘지만 AAC 256은 버틴다. LDAC 같은 코덱이 연결이 나빠지면 660, 330으로 스스로 내려가는 이유다. ② 링크 처리량을 줄이는 것은 거리가 멀어져 3 Mb/s EDR 대신 2 Mb/s나 1 Mb/s 패킷으로 내려간 상황이다(3장). 단순화: 재전송 여유가 30% 미만이면 “위험”, 0 이하면 “끊김”으로 판정했다. 실제 동작은 버퍼 크기와 재전송 정책에 따라 다르다.

소리는 왜 늦게 들릴까: 지연 예산

휴대폰에서 재생 버튼을 누른 순간부터 귀에 소리가 닿기까지 여러 단계가 시간을 더한다.

프레임 모으기: 코덱은 소리를 일정 길이의 프레임으로 잘라 압축한다. LC3는 10 ms(또는 7.5 ms), SBC·AAC는 설정에 따라 수 ms~20 ms 남짓의 표본을 모아야 압축할 수 있다.
인코딩·디코딩: 계산 시간.
전송과 재전송 여유: 패킷이 깨지면 다시 보낼 시간을 남겨 둬야 한다. 여유가 길수록 끊김은 줄고 지연은 늘어난다.
지터 버퍼: 도착 시각이 들쭉날쭉해도 끊김 없이 재생하려고 받는 쪽이 쌓아 두는 양. 클래식 A2DP에서 가장 큰 항목이다.
표시 지연(presentation delay): LE 오디오에서 여러 수신기가 같은 순간에 재생하도록 정한 기준 시각까지의 여유.

카페 공연을 전화로 들려주기

카페의 라이브 공연을 전화로 친구에게 들려준다고 해 보자. 잡음 때문에 가끔 말이 끊기니, 몇 초씩 모아 두었다가 보내면 끊김은 줄지만 친구는 그만큼 늦게 듣는다. 블루투스 오디오도 같다. 재전송 기회와 버퍼를 늘리면 끊김이 줄고 지연이 늘어난다. 음악은 지연을 참을 수 있지만 게임과 통화는 못 참는다.

CALCULATOR

지연 예산 쌓기: 클래식 A2DP vs LE 오디오

클래식: 지터 버퍼 LE: ISO_Interval LE: 재전송 여유 FT (ISO_Interval 개수) LE: 표시 지연

클래식 A2DP 합계—

LE 오디오 합계—

입 모양이 어긋나 보이기 시작하는 감각약 40 ~ 100 ms

막대 하나가 지연 한 항목이다. 해볼 것: ① 클래식의 지터 버퍼를 줄이면 지연은 줄지만, 실제 제품에서는 간섭이 있을 때 끊긴다. 그래서 영상 앱은 운영체제가 알려 주는 지연만큼 화면을 늦춰 입 모양을 맞춘다. ② LE에서 FT를 늘리면 재전송 기회가 늘어 끊김에 강해지지만, 그만큼 지연이 ISO_Interval 단위로 쌓인다. 모델 수치(대표값): 클래식 = 프레임 20 ms + 인코딩 5 + 전송 10 + 버퍼 + 디코딩 5 + DAC 5 ms. LE = LC3 10 ms 프레임 + 인코딩 2.5 + (ISO_Interval × FT) + 표시 지연 + 디코딩 2.5 ms.

LE 오디오의 토대: 등시성 채널

1장의 “예측해 보기”에서 본 것처럼, 4.0의 LE에는 정해진 시각에 꼭 도착해야 하는 데이터를 다루는 규칙이 없었다. 5.2(2019년 말)는 등시성 채널(isochronous channels)을 추가했다. “등시성”이란 같은 간격으로 반복된다는 뜻이다. 데이터에는 유효 기간이 있고, 기한이 지나면 재전송하지 않고 버린다(플러시). 늦은 소리는 소리가 아니기 때문이다.

CIS(Connected Isochronous Stream): 연결된 두 기기 사이의 등시성 스트림. ACL 연결(6장)에 딸려 있고, 확인 응답과 재전송이 있다. 귀마다 CIS 하나씩, 여러 CIS를 묶은 것이 CIG(그룹)다. 같은 CIG의 스트림은 같은 기준 시각에 맞춰 재생된다.
BIS(Broadcast Isochronous Stream): 연결 없이 뿌리는 등시성 스트림. 확인 응답이 없으므로 같은 데이터를 미리 정한 횟수만큼 반복해 신뢰도를 올린다. 최대 31개 BIS를 묶은 것이 BIG다.

그림 10-1. 세 가지 오디오 연결. 클래식 A2DP는 휴대폰과 수신기 하나 사이의 ACL 링크라, 완전 무선 이어폰은 한쪽이 중계하거나 옆에서 같이 듣는 각 회사의 기술이 필요했다. LE 오디오는 귀마다 CIS를 따로 두고 한 CIG로 묶어 같은 시각에 재생한다. Auracast는 연결 없이 BIG로 뿌리므로 확인 응답 대신 같은 데이터를 정해진 횟수만큼 반복하고, 몇 명이 듣든 송신기의 부담은 같다.

CIS는 이런 파라미터로 정의된다.

파라미터	뜻	사양 범위
ISO_Interval	CIS 이벤트 사이 간격	1.25 ms 단위 5 ms ~ 4 s, ACL 감독 타임아웃의 절반 미만
NSE	한 이벤트 안의 최대 서브이벤트 수 (재전송 기회 포함)	max(BN) ~ 31
BN	이벤트마다 새로 들어오는 페이로드 수	0 ~ 15
FT	한 페이로드를 몇 이벤트 동안 보낼 수 있는가(플러시 기한)	필수 지원 값 1
Max_PDU	CIS PDU 하나의 최대 데이터	0 ~ 251바이트

CIS 파라미터와 범위: [Vol 6] Part B §4.5.13.1·§4.5.13.2 · 플러시 기한: §4.5.13.5 · BIS·BIG(최대 31 BIS, BN 1~7, PTO, IRC, NSE ≤ 31): §4.4.6.1~§4.4.6.3 · 등시성 적응 계층(ISOAL, 프레임/비프레임): [Vol 6] Part G · 5.2 새 기능: [Vol 1] Part C §11.1

SIMULATOR

CIS 이벤트: 재전송 기회와 플러시

패킷 손실률 NSE (이벤트당 서브이벤트) FT (플러시 기한, 이벤트)

이론상 전달 확률—

이 실행에서 잃은 프레임—

추가되는 최대 지연—

가로는 CIS 이벤트(ISO_Interval 10 ms, BN = 1: 이벤트마다 새 오디오 프레임 하나). 칸 하나가 서브이벤트, 파랑은 성공, 빨강은 손실, 회색은 이미 성공해 쓰지 않은 서브이벤트, 검정 테두리는 기한이 지나 버린 프레임이다. 해볼 것: ① NSE = 1, FT = 1이면 손실률이 그대로 끊김률이다. ② NSE를 3으로 올리면 한 이벤트 안에서 두 번 더 기회가 생겨 지연 증가 없이 신뢰도가 크게 오른다(대신 공중 시간을 더 예약한다). ③ FT를 올리면 다음 이벤트까지 기다려 다시 보낼 수 있다. 신뢰도는 오르지만 지연이 ISO_Interval씩 늘어난다. 이론값: 1 − p^(NSE/BN)×FT(손실이 서로 독립이라고 가정).

LE 오디오의 코덱 LC3(Low Complexity Communication Codec)는 SBC보다 낮은 비트레이트에서 더 좋은 음질을 내도록 설계되었다. 같은 음질을 적은 비트로 보내면 공중 시간이 줄고, 그 시간을 재전송 기회(NSE)에 쓸 수 있다. LE 오디오는 그래서 “더 적게 보내고 더 여러 번 보내는” 쪽을 택했다. 보청기용 프로파일(HAP)이 LE 오디오 위에 만들어진 것도, 작은 배터리로 하루 종일 두 귀에 소리를 넣어야 하기 때문이다.

LE 오디오의 다음 과제는 무손실·고해상도 음원이다. CD 음질만 해도 1,411 kb/s라 LE 2M의 실제 처리량(약 1.4 Mb/s, 6장)으로는 재전송 여유가 없다. 다음 Core 사양에 들어갈 예정인 HDT(공개 초안, Core 6.3에도 없음)는 LE 속도를 최대 7.5 Mb/s로 올려 이런 쓰임새와 더 낮은 지연을 겨냥한다(3장).

Auracast: 한 송신기, 수많은 귀

LE 오디오의 브로드캐스트 오디오(Auracast™)는 BIS로 소리를 뿌린다. 받는 이어폰 수에 제한이 없다. 공항 안내 방송을 보청기로 직접 듣고, 체육관의 TV 소리를 각자 이어폰으로 듣고, 친구의 휴대폰 음악을 여럿이 함께 듣는 데 쓴다.

송신기는 확장 광고(5장)로 “방송이 있다”를 알리고, 주기적 광고를 시작한다.
주기적 광고에는 BIG의 시각·채널·파라미터를 담은 BIGInfo가 실린다.
이어폰은 주기적 광고에 동기를 맞춘 뒤 BIGInfo를 읽고 원하는 BIS에 동기화해 듣는다. 연결은 없다.
공개 방송이 아니면 BIG를 암호화하고, 듣는 사람은 Broadcast_Code(방송 비밀번호)를 알아야 한다. 휴대폰 같은 “도우미” 기기가 QR 코드나 메뉴로 방송을 고르고 이어폰에 코드를 전달할 수 있다.

BIG 이벤트·BIGInfo·연관 주기적 광고·암호화: [Vol 6] Part B §4.4.6.4~§4.4.6.11 · 암호화된 BIG와 Broadcast_Code: [Vol 3] Part C §10.9 · Auracast의 방송 탐색·도우미 역할은 Core 밖의 프로파일(BAP, BASS, PBP 등)

예측해 보기

Auracast 방송을 듣는 이어폰이 100개로 늘었다. 송신기가 보내야 하는 데이터는 어떻게 될까?

BIS에는 확인 응답이 없다는 점을 떠올려 보자.

브로드캐스트는 수신자 수와 무관하다. 대신 아무도 “못 받았다”고 말해 주지 않으므로, 송신기는 미리 정한 반복(IRC)과 사전 전송(PTO)으로 신뢰도를 확보한다. 연결형 CIS로 100명에게 보내려면 100개의 스트림이 필요하다.

핵심 정리

클래식 오디오: 음악은 A2DP(ACL·L2CAP, 재전송 + 큰 버퍼), 통화는 HFP(SCO/eSCO, 예약 슬롯). HV3는 30바이트를 3.75 ms마다, 64 kb/s, 재전송 없음.
코덱 비트레이트가 높을수록 공중 시간과 재전송 부담이 커져 간섭에 약하다. 손실률 p이면 필요한 공중 시간 ≈ 비트레이트 ÷ (1 − p).
지연 = 프레임 + 인코딩 + 전송·재전송 여유 + 지터 버퍼 + 디코딩. 클래식 A2DP는 버퍼 때문에 보통 100 ms를 넘고, LE 오디오는 수십 ms로 줄일 수 있다.
5.2의 등시성 채널: 연결형 CIS(재전송 있음, CIG로 귀마다 묶음)와 방송형 BIS(확인 없음, BIG ≤ 31). ISO_Interval 5 ms ~ 4 s, NSE ≤ 31, 기한(FT)이 지난 데이터는 버린다.
Auracast는 확장 광고 → 주기적 광고(BIGInfo) → BIS 동기화로 듣는 브로드캐스트다. 청취자 수와 무관하며, 비공개 방송은 Broadcast_Code로 암호화한다.

확인 퀴즈

음악을 듣다가 전화를 받으면 이어폰 음질이 갑자기 먹먹해지는 주된 이유는?

클래식에서 마이크를 쓰는 양방향 통화는 HFP로 처리된다. CVSD(8 kHz)나 mSBC(16 kHz) 같은 음성 코덱은 음악 코덱보다 대역이 훨씬 좁다.

SCO 링크가 깨진 패킷을 재전송하지 않는 이유는?

등시성 데이터의 원칙이다. eSCO는 짧은 재전송 창을 두어 기한 안에서만 다시 보내는 절충을 했고, LE의 CIS는 플러시 기한(FT)으로 같은 생각을 일반화했다.

CIS에서 NSE를 1에서 3으로 늘리고 FT는 1로 둔다. 무엇이 일어나나?

서브이벤트는 한 ISO_Interval 안에 있으므로 플러시 기한은 그대로다. 손실률 20%라면 전달 실패 확률이 20%에서 0.8%로 준다.

BIS(브로드캐스트)가 신뢰도를 높이는 방법은?

BIS는 단방향이라 확인 응답이 없다. BIG 파라미터(NSE, IRC, PTO)로 반복과 사전 전송을 정한다.

Core 6.3에서 CIS의 ISO_Interval로 허용되지 않는 값은?

ISO_Interval은 1.25 ms 단위로 5 ms ~ 4 s이고, 연결된 ACL 감독 타임아웃의 절반보다 작아야 한다.