이 글은 habr.com 사이트에 올라왔던 “Audio over Bluetooth: most detailed information about profiles, codecs, and devices” 글을 번역한 것이다. 원문: https://habr.com/en/post/456182/

3.5 mm 오디오 잭이 없는 스마트폰이 시장의 주력 상품이 되면서 헤드폰 업계에는 대격변이 일어났습니다. 많은 사용자들은 블루투스 헤드폰을 사용하여 음악을 듣고 통화를 하게 되었습니다. 그러나 블루투스 장치 제조사들은 자세한 제품 정보를 잘 공개하지 않으려고 하고, 인터넷에 있는 블루투스 오디오에 대한 글은 때때로 서로가 모순되거나 정확하지 않기도 합니다. 이러한 글에서는 모든 기능을 언급하지도 않으며, 틀린 정보를 담고 있기도 합니다. 이 글에서는 블루투스 프로토콜, 블루투스 스택, 헤드폰, 스피커, 음악과 통화용 블루투스 코덱의 기능, 전송되는 오디오의 품질과 지연 시간에 영향을 주는 요소, 지원하는 코덱과 장치가 지원하는 기타 기능 정보를 캡처하고 디코드하는 방법에 대해서 알아 볼 것입니다.

TL;DR:

• SBC 코덱은 괜찮습니다
• 헤드폰에는 코덱별 이퀄라이저와 후처리 설정이 존재합니다
• aptX는 광고 문구만큼 대단한 것이 아닙니다
• LDAC는 단지 마케팅 용어입니다
• 음성 통화 품질은 여전히 좋지 않습니다
• 웹 브라우저는 C 언어로 된 오디오 인코더를 emscripten을 사용하여 WebAssembly로 컴파일 및 실행할 수 있으며, 이 과정에서 지연은 발생하지 않습니다.

블루투스로 음악 듣기

블루투스 장치의 기능은 블루투스 표준 문서에 정의되어 있는 프로필로 정해집니다. 블루투스 음악은 고품질 오디오용 A2DP 전송 프로필을 사용합니다. A2DP 표준은 2003년에 최초로 정의되었으며, 그 이후로 큰 변화는 없었습니다.

A2DP 프로필에서 정의하는 유일한 필수 코덱은 SBC이며, 추가로 3종류의 선택적 코덱이 있습니다. SBC 코덱은 계산 복잡도가 낮으며 블루투스 용도로 개발되었습니다. 제조사에서는 A2DP에 포함되어 있지 않은 제조사별 코덱을 사용할 수도 있습니다.

2019년 6월 기준, XKCD 만화에서 보는 것처럼 14개의 A2DP 코덱이 알려져 있습니다:

• SBC ← A2DP에 포함됨, 모든 장치에서 지원
• MPEG-1/2 Layer 1/2/3 ← A2DP에 포함됨: 잘 알려진 MP3, 디지털 TV에서 자주 사용되는 MP2, 더 이상 사용되지 않는 MP1
• MPEG-2/4 AAC ← A2DP에 포함됨
• ATRAC ← 소니의 구형 코덱, A2DP에 포함됨
• LDAC ← 소니의 신형 코덱
• aptX ← 1988년에 개발된 코덱
• aptX HD ← aptX와 동일하나 인코딩 프로필이 다름
• aptX Low Latency ← 완전히 다른 코덱, 소프트웨어 구현 없음 버퍼 용량이 작은 aptX
• aptX Adaptive ← 퀄컴에서 개발한 또 다른 코덱
• FastStream ← 의사 코덱(pseudo-codec), SBC를 기반으로 함
• HWA LHDC ← 화웨이의 신형 코덱
• Samsung HD ← 2종류의 장치에서 지원
• Samsung Scalable ← 2종류의 장치에서 지원
• Samsung UHQ-BT ← 3종류의 장치에서 지원

블루투스 EDR을 사용하면 2-3 Mb/s로 데이터를 전송할 수 있으며, 비압축 16비트 PCM 2채널 데이터는 1.4 Mb/s의 대역폭만을 필요로 하는데 애시당초 왜 코덱이 필요했을까요?

블루투스 데이터 전송

블루투스에는 두 가지 데이터 전송 방식이 있습니다. ACL(Asynchronous Connection Less) 모드는 연결을 맺지 않고 비동기식으로 데이터를 전송하며, SCO(Synchronous Connection Oriented) 모드는 연결을 맺고 동기식으로 데이터를 전송합니다.

데이터 전송은 시분할 방식으로 이뤄지며, 각각 데이터 패킷마다 주파수 채널을 바꿉니다(Frequency-Hop/Time-Division-Duplex, FH/TDD). 시간은 슬롯이라고 불리는 625마이크로초 단위의 간격으로 나뉩니다. 일부 장치는 짝수번 슬롯에 데이터를 전송하고, 다른 장치는 홀수번 슬롯에 데이터를 전송합니다. 전송된 패킷은 데이터 크기와 전송 모드에 따라서 1, 3 또는 5개의 슬롯을 점유할 수 있습니다. 만약 패킷이 충분히 크고 1개 초과 슬롯을 사용해서 전송해야 한다면 데이터는 전송이 끝날 때까지 짝수번과 홀수번 슬롯으로 전송됩니다. 만약 각각 패킷이 1개 슬롯만 사용하고 양쪽 장치가 연속적으로 데이터를 주고받는다면 1초에 최대 1600개까지의 패킷을 보내고 받을 수 있습니다.

각종 장치 사양과 블루투스 웹 사이트에 나타난 대로, EDR에서 사용하는 2 또는 3 Mbps 전송률은 동시에 양방향으로 전송되는 데이터를 모두 합친(데이터를 캡슐화하는 프로토콜의 기술적인 헤더도 전부 포함) 최대 전송률입니다. 실제 데이터 전송률은 일정하지 않습니다.

음악 스트리밍은 비동기식으로 이뤄지며, 2-DH5 및 3-DH5 패킷을 사용합니다. 해당 패킷은 EDR 모드에서 각각 최대 2 Mb/s, 3 Mb/s까지의 전송률을 지원하며 5개의 시분할 슬롯을 점유합니다.

시분할 원칙에 의해서, 하나의 패킷을 전송한 후 두 번째 장치에서 아무 것도 전송하지 않았거나 작은 패킷을 전송했다면 625마이크로초 시간 슬롯을 기다려야 하며, 두 번째 장치에서 더 큰 패킷으로 전송했다면 더 오래 기다려야 합니다. 두 개 이상의 장치(헤드폰, 스마트 워치, 피트니스 트래커 등)가 휴대폰에 연결되어 있다면 전송 시간은 모든 장치가 공유합니다.

A2DP 오디오 스트리밍은 L2CAP와 AVDTP 전송 프로토콜로 캡슐화되어야 하며 패킷에서 오디오를 전송할 수 있는 최대 공간에서 16바이트를 차지합니다.

패킷 형식	슬롯 개수	패킷당 바이트 수	최대 A2DP 페이로드 바이트	최대 A2DP 페이로드 비트레이트
2-DH3	3	367	351	936 kb/s
3-DH3	3	552	536	1429 kb/s
2-DH5	5	679	663	1414 kb/s
3-DH5	5	1021	1005	2143 kb/s

실제 상황에서 비압축 오디오를 전송하기에는 1414 및 1429 kbps는 충분하지 않습니다. 2.4 GHz 대역은 여러 장치가 공유하고 서비스 데이터도 전송해야 하기 때문입니다. EDR 3 Mbps 모드를 사용하려면 높은 전송 전력과 신호대 잡음비가 필요하지만, 실제 상황에서는 짧은 끊김이 종종 발생하기에 PCM을 안정적으로 전송할 수 없으며, 가능하다고 하더라도 수 미터 이내의 거리에서만 안정적입니다.

실제로도 990 kb/s 오디오 스트림(LDAC 990 kb/s)도 안정적으로 전송하기 쉽지 않습니다.

이제 코덱으로 돌아갑시다.

SBC

이 코덱은 A2DP 표준을 지원하는 장치에서 필수로 지원해야 하는 코덱입니다. 최적의 코덱이자 최악의 코덱이기도 합니다.

샘플링 레이트	비트 해상도	비트 전송률	인코딩 지원	디코딩 지원
16, 32, 44.1, 48 kHz	16비트	10-1500 kb/s	모든 장치	모든 장치

SBC는 빠르게 연산할 수 있는 간단한 코덱이며, 간단한 청각 마스킹(auditory masking)을 사용하는 원시적인 심리 음향 모델(psychoacoustic model)이 적용된 적응형 펄스 코드 부호화(APCM, Adaptive PCM)를 사용합니다.

A2DP 표준에서는 중간 품질(Middle Quality), 고품질(High Quality) 두 가지의 프로필을 추천하고 있습니다.

코덱 설정으로 알고리즘에 의한 지연, 블록당 샘플 개수, 비트 할당 알고리즘을 제어할 수 있으나, 대개의 경우 표준에서 정의한 인자(조인트 스테레오, 주파수 대역 8종류, 오디오 프레임당 16블록, 라우드니스 비트 할당)를 사용합니다.

SBC에서는 비트 전송률에 직접 영향을 주는 비트풀(bitpool) 인자를 유동적으로 조정할 수 있습니다. 오디오가 지연되었거나, 패킷이 손실되었거나, 장치가 너무 멀리 떨어져 있다면 오디오 소스에서 비트풀을 줄여서 오디오 끊김을 방지하며 연결이 다시 안정화되었을 때 비트풀을 늘릴 수 있습니다.

대부분 헤드폰 제조사에서는 최대 비트풀 인자를 53으로 설정하며, 이 경우 권장 프로필을 사용하면 최대 비트 전송률은 328 kbps로 제한됩니다.

헤드폰 제조사에서 최대 비트풀 값을 53 이상으로 설정했다고 하더라도(Beats Solo³, JBL Everest Elite 750NC, Apple AirPods 및 일부 리시버와 자동차 헤드 유닛 등에서 실제로 사용함) 대부분 OS에서는 블루투스 스택의 내부 제한 때문에 높은 비트 전송률을 사용하지 못합니다.

또 다른 제조사에서는 최대 비트풀 값을 낮게 설정하기도 하며, 이는 음질을 악화시킵니다. 예를 들어 Bluedio T에서는 39, 삼성 기어 아이콘X에서는 37로 설정합니다.

블루투스 스택에서 인위적인 제한을 가한 가능성 있는 이유는 인증 테스트를 충분히 거치지 못했거나, 일부 장치에서는 자주 사용되지 않는 프로필이나 큰 비트풀 값을 지원한다고 하더라도 실제로 사용했을 때 호환성 문제가 발생하기 때문입니다. 개발자 입장에서는 잘못 구현된 장치 데이터베이스를 만들기보다는 추천하는 프로필에서 제안하는 값으로 옵션을 제한하는 것이 더 쉬웠을 것입니다. 비록 지금은 제대로 동작하지 않는 기능의 데이터베이스가 존재합니다.

SBC는 저주파 대역부터 고주파 대역 순 주파수 대역별로 양자화 비트를 동적 할당하며, 각각 대역마다 다른 가중치를 설정합니다. 만약 전체 비트 전송률이 저주파 대역과 중주파 대역에서 사용되었다면 고주파 대역은 묵음으로 대체되어 잘려 나갑니다.

SBC 328 kbps의 예를 들어 봅시다. 원본 오디오는 위쪽, SBC로 인코딩한 오디오는 아래쪽에 있습니다. 비교를 위해서 트랙을 전환했습니다. 비디오 파일의 오디오 스트림은 FLAC 무손실 코덱으로 압축되었습니다. MP4 컨테이너에서 FLAC을 사용하는 것은 공식 표준에 포함되어 있지 않기 때문에 일부 웹 브라우저에서 아래 예제를 재생하지 못할 수도 있습니다(데스크톱 Chrome이나 Firefox의 최신 버전에서는 작동함). 오디오를 들을 수 없다면 파일을 다운로드해서 직접 재생해 보십시오.

스펙트로그램에서 전환하는 순간을 볼 수 있습니다. SBC 코덱에서는 17.5 kHz 이상의 고주파 대역을 주기적으로 잘라내며, 20 kHz 이상의 대역에는 비트를 할당하지 않습니다. 스펙트로그램은 클릭해서 확대할 수 있습니다(1.7 MB).

원 저자는 이 곡의 원본과 SBC 인코딩된 것을 구분할 수 없다고 밝혔습니다.

이제 또 다른 것을 알아봅시다. 비트풀 값을 37로 변경하여 삼성 기어 아이콘X의 음질을 시뮬레이션해 보겠습니다(위쪽: 원본 스트림, 아래쪽: SBC 239 kbps, 오디오 인코딩: FLAC).

원 저자는 탁탁거리는 소리, 작은 스테레오 효과 및 고주파 대역 보컬에서 불쾌한 치찰음을 들을 수 있었습니다.

정리하자면 SBC는 매우 유연한 코덱입니다. 저지연 모드로 설정할 수도 있으며, 높은 비트 전송률(452 kb/s 이상)에서 고음질을 제공하며, 표준 고음질(328 kb/s) 모드에서 대부분 경우에 만족할 만한 음질을 제공합니다. 그러나 이 코덱이 저음질로 알려지게 된 데에는 몇 가지 이유가 있습니다. A2DP 표준에서는 고정된 프로필을 정의하지 않으며(단지 추천만 함), 블루투스 스택 개발자들은 비트풀을 인위적으로 제한하며, 사용자 인터페이스에는 전송되는 오디오 설정이 표시되지 않으며, 헤드폰 제조사에서는 비트풀 값을 임의로 설정할 수 있으며 해당 설정값을 제품 상세 정보에 기재하지 않기 때문입니다.

같은 비트풀을 사용했다고 하더라도 프로필에 따라서 비트 전송률이 달라집니다. 예를 들어서 같은 비트풀 53을 사용했다고 하더라도 추천하는 고음질 프로필에서는 328 kbps, 듀얼 채널 모드와 주파수 대역 4종류 사용 시에는 1212 kbps 비트 전송률을 사용합니다. 그래서 OS 제작사에서는 비트풀 제한과 더불어 비트 전송률 제한도 둡니다. A2DP 표준 그 자체의 결함 때문에 이 문제가 발생했다고 봅니다. 프로필에서는 비트풀이 아닌 비트 전송률을 협상해야 했습니다.

OS별 SBC 구현에서 지원하는 기능입니다:

OS	샘플링 레이트	최대 비트풀 제한	최대 비트 전송률 제한	일반적 비트 전송률	동적 비트풀 지원
Windows 10	44.1 kHz	53	512 kb/s	328 kb/s	✓*
리눅스 (BlueZ + PulseAudio)	16, 32, 44.1, 48 kHz	64(들어오는 연결), 53 (나가는 연결)	제한 없음	328 kb/s	✓*
macOS High Sierra	44.1 kHz	64, 기본값 53***	알 수 없음	328 kb/s	✗
안드로이드 4.4-9	44.1/48 kHz**	53	328 kb/s	328 kb/s	✗
안드로이드  4.1-4.3.1	44.1, 48 kHz**	53	229 kb/s	229 kb/s	✗
블랙베리 OS 10	48 kHz	53	제한 없음	328 kb/s	✗

* 비트풀은 자동으로 감소하지만, 전송 조건이 달라져도 자동으로 증가하지는 않습니다. 비트풀을 되돌리려면 재생을 중지하고 몇 초 동안 기다린 다음 오디오를 다시 재생해야 합니다.

** 기본값은 펌웨어를 컴파일할 때 스택 설정에 따라 다라집니다. 안드로이드 8/8.1에서는 컴파일 시간 설정에 따라서 44.1 kHz나 48 kHz 중 하나로 결정되며, 다른 버전에서는 44.1 kHz와 48 kHz를 동시에 지원합니다.

*** Bluetooth Explorer 소프트웨어를 사용하여 비트풀 값을 조정할 수 있습니다.

aptX와 aptX HD

aptX는 빠르게 연산할 수 있는 간단한 코덱이며, 심리 음향 모델을 사용하지 않으며, 적응형 차분 펄스 코드 부호화(ADPCM)를 사용합니다. 이 코덱은 1988년 주변부터 사용되기 시작했습니다(특허 출원은 1988년 2월). 이 코덱은 블루투스 이전에는 전문적인 무선 오디오 장치에 사용되었습니다. 현재 퀄컴에서 소유하고 있으며, 라이선스 허가를 받고 비용을 지불해야 합니다. 2014년 기준 허가 비용은 1회의 $6,000 및 최대 10,000대의 장치까지 장치마다 약 $1입니다.(출처, 16쪽)

코덱에서 설정할 수 있는 유일한 인자는 샘플링 레이트입니다. 채널 개수나 모드 설정 옵션 등이 있지만 대부분 장치에서는 스테레오만 지원합니다(70개 이상의 모델에서 확인함).

코덱	샘플링 레이트	비트 해상도	비트 전송률	인코딩 지원	디코딩 지원
aptX	16, 32, 44.1, 48 kHz	16비트	128 / 256 / 352 / 384 kb/s (샘플링 레이트에 따라 다름)	Windows 10(데스크톱과 모바일), macOS, 안드로이드 4.4+/7*, 블랙베리 OS 10	다양한 장치(하드웨어 디코딩)

* 7 이하의 버전에서는 블루투스 스택을 수정해야 합니다. OS에 인코딩 라이브러리가 포함되었다고 하더라도 안드로이드 장치 제조사에서 퀄컴에 코덱 사용 라이선스를 얻었을 때만 지원합니다.

aptX는 오디오를 4개의 주파수 대역으로 분할하고 각각 대역마다 고정된 비트 수를 사용하여 양자화 과정을 거칩니다. 0-5.5 kHz까지 8비트, 5.5-11 kHz까지 4비트, 11-16.5 kHz까지 2비트, 16.5-22 kHz까지 2비트(44.1 kHz 샘플링 레이트 기준).

aptX 오디오 예제(위쪽: 원본 오디오, 아래쪽: aptX 인코딩된 오디오, 왼쪽 채널의 스펙트로그램만 있음, FLAC으로 압축됨):

고주파 대역이 약간 붉게 표시되지만 원 저자는 차이를 들을 수 없었습니다.

코덱의 양자화 비트 분할이 고정되어 있기 때문에, 다른 주파수 대역에서 더 많은 비트가 필요하다고 해도 비트를 “넘겨줄” 수 없습니다. SBC와는 다르게 aptX는 주파수를 인위적으로 “자르지” 않지만 양자화 노이즈를 추가하여 오디오의 다이나믹 레인지를 감소시킵니다.

가령 한 대역에 2비트를 사용한다고 하더라도 다이나믹 레인지가 12 dB 감소한다고 가정해서는 안 됩니다. ADPCM에서는 2비트 양자화를 사용한다고 해도 최대 96 dB까지의 다이나믹 레인지를 지원하지만 특정한 종류의 신호에만 해당합니다.

현재 값의 절댓값을 수치로 저장하는 PCM과는 다르게, ADPCM은 현재 값과 다음 값의 차이를 수치로 저장합니다. 따라서 같은 데이터(무손실)나 거의 같은 데이터(약간의 반올림 오류)를 저장할 때 필요한 비트 수를 줄일 수 있습니다. 반올림 오류를 줄이기 위해서 인수 테이블(factor table)을 사용합니다.

코덱을 개발할 때 음악 오디오 파일을 기반으로 하여 ADPCM 계수를 계산했습니다. 테이블을 만들 때 사용한 음악 모음과 오디오 시그널이 비슷할수록 aptX에 의한 양자화 오류(노이즈)는 더 줄어듭니다.

그래서 인위적으로 생성한 테스트 결과는 항상 음악보다 더 나쁩니다. aptX가 잘 작동하지 못하는 인위적인 테스트로 12.4 kHz 사인파를 만들어 보았습니다. (위쪽: 원래 신호, 아래쪽: aptX 인코딩. FLAC 오디오. 귀갱 주의!):

스펙트럼 그래프:

노이즈를 명확하게 들을 수 있습니다.

그러나 진폭이 더 낮은(더 조용한) 사인파를 생성하면 노이즈 크기도 동시에 줄어듭니다. 이로서 다이나믹 레인지의 범위를 알 수 있습니다:

원래 음악 트랙과 압축된 트랙의 차이를 들어 보려면 신호를 반전한 다음 각각 채널에 트랙을 합산하는 방법이 있습니다. 이 방식은 대개의 경우 정확하지 않으며 복잡한 코덱을 사용한다면 올바른 결과가 나오지 않을 가능성이 높지만, ADPCM 수준의 코덱에서는 이 방식에 큰 오류가 없습니다.

원본과 aptX 인코딩된 오디오의 차이

신호 차이의 제곱 평균 제곱근(root mean square)은 -37.4 dB이며, 압축되었음을 감안해도 작습니다.

aptX HD

aptX HD는 독립된 코덱이 아니며, 단지 개선된 aptX 인코딩 프로필일 뿐입니다. 인코딩할 때 각각 주파수 대역별로 사용하는 비트 수가 변경되었습니다.0-5.5 kHz까지 10비트, 5.5-11 kHz까지 6비트, 11-16.5 kHz까지 4비트, 16.5-22 kHz까지 4비트(44.1 kHz 기준).

코덱	샘플링 레이트	비트 해상도	비트 전송률	인코딩 지원	디코딩 지원
aptX HD	16, 32, 44.1, 48 kHz	24비트	192 / 384 / 529 / 576 kb/s (샘플링 레이트에 따라 다름)	안드로이드 8+*	일부 오디오 장치(하드웨어)

* 7 이하의 버전에서는 블루투스 스택을 수정해야 합니다. OS에 인코딩 라이브러리가 포함되었다고 하더라도 안드로이드 장치 제조사에서 퀄컴에 코덱 사용 라이선스를 얻었을 때만 지원합니다.

이 코덱은 aptX보다 자주 사용되지는 않습니다. 퀄컴에서 별개의 라이선스 계약과 라이선스 비용을 지불해야 하는 것 같습니다.

12.4 kHz 사인파를 인코딩해 보겠습니다:

aptX보다 더 좋지만 여전히 잡음이 있습니다.

aptX Low Latency

aptX의 저지연 버전 역시 독립된 코덱이 아닙니다. aptX와의 차이점은 지연 시간과 오디오 유닛에 적용된 버퍼 설정 뿐입니다. 이것을 제외하면 aptX와 동일합니다.

오디오 지연을 프로그램으로 조절할 수 없는 영화나 게임과 같은 저지연 인터랙티브 오디오에서의 사용을 위해서 설계되었습니다. 델에서 개발한 인텔 블루투스 칩셋 드라이버에서 소프트웨어적으로 지원합니다. 일부 트랜스미터, 리시버, 헤드폰, 스피커에서 지원하나 스마트폰에서는 찾아 보기 어렵습니다.

샘플링 레이트	비트 전송률	인코딩 지원	디코딩 지원
44.1 kHz	352 kb/s	델 드라이버가 설치된 Windows 및 일부 트랜스미터(하드웨어)	일부 오디오 장치(소프트웨어)

AAC

AAC(Advanced Audio Coding)는 복잡한 심리 음향 모델이 적용된 연산하기 복잡한 코덱입니다. 인터넷에서의 오디오 전송에 폭낣게 사용되며, MP3 다음으로 많이 사용됩니다. AAC를 사용하려면 라이선스 허가를 받고 비용을 지불해야 합니다. 1회 지불 $15,000(15인 이하 회사의 경우 $1,000) 및 첫 500,000대의 장치까지 장치당 $0.98입니다(출처).

코덱은 MPEG-2 및 MPEG-4 표준에 정의되어 있으며, 많은 사람들의 생각과는 다르게 애플의 독점 코덱이 아닙니다.

샘플링 레이트	비트 전송률	인코딩 지원	디코딩 지원
8 — 96 kHz	8 — 576 kb/s (스테레오), 256 — 320 kb/s (블루투스에 주로 사용)	macOS, 안드로이드 7+*, iOS	다양한 장치(하드웨어)

* 제조사에서 로열티를 지불한 장치만 해당

iOS와 macOS에는 현재 시점에서 가장 고품질로 인코딩하는 애플 AAC 인코더가 포함되어 있습니다. 안드로이드는 애플 AAC 다음으로 음질이 좋은 프라운호퍼 FDK AAC 인코더를 사용하지만, 다양한 SoC 제조사의 플랫폼 내장형 하드웨어 인코더를 사용할 수도 있습니다. SoundGuys 웹 사이트에 올라온 테스트 결과에 의하면 안드로이드 휴대폰마다 AAC 인코딩 음질에 큰 차이가 있었습니다:

대부분의 무선 오디오 장치에서는 최대 320 kbps AAC 비트 전송률을 지원하며, 일부는 최대 256 kbps까지만 지원합니다. 다른 비트 전송률은 거의 사용되지 않습니다.

320 kbps와 256 kbps의 AAC 품질 자체는 나쁘지 않지만, 이미 압축된 오디오의 재압축 손실(generation loss)에 취약합니다. iOS에서는 원본과 AAC 256 kbps의 차이를 듣기 힘들며, 여러 번 다시 인코딩되어도 차이는 거의 없습니다. MP3 320 kbps를 AAC 256 kbps로 다시 인코딩했다고 하더라도 차이를 무시할 수 있습니다.

다른 블루투스 코덱과 마찬가지로 음악이 재생될 때 한 번 디코딩된 후 다른 코덱으로 인코딩됩니다. AAC 형식의 음악을 듣는다고 하더라도 OS에서 디코딩을 거친 다음 블루투스로 전송하려고 다시 AAC로 인코딩합니다. 음악과 새 메시지 알림 등 여러 오디오 스트림을 혼합하려면 불가피하며, iOS라고 해도 예외가 아닙니다. iOS에서 블루투스로 음악을 들을 때 트랜스코딩 과정을 거치지 않는다는 여러 언급이 있으나 이는 잘못된 사실입니다.

AAC 표준 인코딩 방법 외에도 여러 가지 확장이 있습니다. 블루투스에서 사용하는 확장 중에는 SLS(Scalable To Lossless)가 있으며, 오디오를 손실 없이 전송할 수 있습니다. 그러나 현재까지 출시된 장치 중에서는 SLS를 지원하는 장치가 없습니다. 전송 지연을 최소화할 수 있는 AAC-LD(Low Delay)는 아직 블루투스에서 사용하도록 표준화되지 않았습니다.

MP1/2/3

MPEG-1/2 Part 3 코덱은 잘 알려진 MP3, 덜 알려진 MP2(디지털 TV와 라디오에 사용됨) 및 거의 알려지지 않은 MP1로 구성되어 있습니다.

과거에 사용되었던 MP1과 MP2 코덱은 지원되지 않으며, 인코딩이나 디코딩을 지원하는 블루투스 헤드폰이나 블루투스 코덱도 존재하지 않습니다.

일부 헤드폰에서는 MP3 디코딩을 지원하지만, 최근에 사용되는 운영 체제에서는 인코딩을 지원하지 않습니다. Windows의 서드파티 블루투스 스택인 BlueSoleil에서는 설정 파일을 직접 편집하면 MP3 인코딩을 사용할 수 있다고 알려져 있지만, 원 저자가 Windows 10에서 시험해 본 결과 파란 화면이 떴습니다. 즉 블루투스 오디오에 사용할 수 없었습니다.

A2DP가 보급되기 전이었던 2006년-2008년에는 심비안과 Windows Mobile용으로 출시되었던 MSI BluePlayer 프로그램과 노키아 BH-501 헤드셋의 조합으로 MP3 음악을 들을 수 있었습니다. 당시 스마트폰 OS 아키텍처에서는 외부 프로그램이 시스템의 저수준 기능에 접근할 수 있었으며, Windows Mobile에는 서드파티 블루투스 스택을 설치할 수도 있었습니다.

MP3 코덱의 마지막 특허는 만료되었으며, 2017년 4월 23일부터 코덱 라이선스 비용을 지불할 필요가 없습니다.

If the longest-running patent mentioned in the aforementioned references is taken as a measure, then the MP3 technology became patent-free in the United States on 16 April 2017 when U.S. Patent 6,009,399, held by and administered by Technicolor, expired.

출처: www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html

샘플링 레이트	비트 전송률	인코딩 지원	디코딩 지원
16 — 48 kHz	8 — 320 kb/s	없음	일부 오디오 장치(하드웨어)

LDAC

소니에서 개발하고 활발하게 밀어 주고 있는 “Hi-Res” 코덱입니다. 96 kHz까지의 샘플링 레이트와 24비트 해상도를 지원하며, 최대 비트 전송률은 990 kbps입니다. 기존 블루투스 코덱을 대체하는 오디오파일용 코덱으로 마케팅하고 있습니다. 무선 전송 조건에 따라서 비트 전송률을 조정하는 적응형 비트 전송률을 지원합니다.

LDAC 인코더(libldac)는 표준 안드로이드 배포판에 포함되어 있으며, 안드로이드 8 이상부터 모든 안드로이드 스마트폰에서 LDAC 인코딩을 지원합니다. 소프트웨어 기반 디코더는 무료로 공개된 것이 없으며 코덱 표준 역시 공개되어 있지 않습니다. 그러나 인코더를 분석해 보았을 때 내부 동작 방식은 플레이스테이션 4와 비타에서도 사용했던 소니의 ATRAC9 코덱과 상당히 유사했습니다. 두 코덱은 모두 주파수 영역(frequency domain)에서 작동하며, 수정된 이산 코사인 변환(MDCT)과 허프만 코딩을 사용합니다.

LDAC는 오디오를 12 또는 16개의 주파수 대역으로 나눕니다. 44.1 kHz와 48 kHz에서는 12개, 88.2 kHz와 96 kHz에서는 16개로 나눕니다.

LDAC는 대부분 소니 헤드폰에서만 지원합니다. 다른 제조사의 헤드폰이나 DAC에서도 지원하기는 하지만 매우 드뭅니다.

샘플링 레이트	비트 전송률	인코딩 지원	디코딩 지원
44.1 — 96 kHz	303/606/909 kb/s (44.1과  88.2 kHz), 330/660/990 kb/s (48과 96 kHz)	안드로이드 8+	일부 소니 헤드폰 및 일부 다른 제조사의 장치(하드웨어)

LDAC를 “Hi-Res” 코덱으로 마케팅하려는 의도 때문에 일부 적절하지 못한 기술적인 선택이 있었습니다. CD 품질 오디오를 여전히 무손실 압축할 수 없음에도 불구하고 인간이 들을 수 없는 비가청 주파수 영역을 인코딩하고 전송하는 데 비트를 사용하고 높은 비트 해상도를 사용하는 것은 적절하지 못한 선택입니다. CD 오디오 전송과 Hi-Res 오디오 전송 두 가지 모드를 사용할 수 있으며, CD 오디오 전송 시에는 무선(over-the-air)으로 44.1 kHz/16비트만 전송됩니다.

무료로 공개된 LDAC 소프트웨어 디코더가 없기 때문에 LDAC를 지원하는 장치 없이 코덱을 테스트할 수는 없었습니다. SoundGuys.com에서 LDAC를 지원하는 DAC의 디지털 출력에 연결하여 녹음한 테스트 결과에 의하면 CD 음질 모드의 LDAC 660 및 990 kbps의 신호대 잡음비는 aptX HD보다 약간 더 높았습니다.

LDAC는 기존 프로필 외에도 138 kbps부터 990 kbps 사이의 유동적 비트 전송률을 지원합니다. 하지만 현재의 안드로이드 장치에서는 표준화된 303/606/909 및 330/660/990 kbps 프로필만 사용합니다.

기타 코덱

다른 A2DP 코덱은 많이 사용되지 않습니다. 이러한 코덱은 거의 지원되지 않거나, 일부 헤드폰과 스마트폰에서만 지원합니다.

A2DP에서 표준화된 ATRAC 코덱은 소니에서도 사용된 적이 없었습니다. 삼성 HD, 삼성 Scalable, 삼성 UHQ-BT 코덱은 송신 및 수신이 가능한 장치가 한정되어 있습니다. 화웨이 LHDC 코덱은 나온 지 얼마 되지 않았으며 3종류(?)의 장치에서만 지원합니다.

오디오 장치의 코덱 지원

많은 제조사에서 무선 헤드폰, 스피커, 리시버, 트랜스미터에 사용되는 코덱 정보를 정확하게 공개하지 않습니다. 일부 기기에서는 제조사에서는 특정 코덱을 “지원”한다고 표시되어 있으나 송신은 지원하나 수신은 지원하지 않습니다(수신기와 송신기가 결합된 장치의 경우 중요함). 이러한 사실은 별도로 표기되어 있지 않습니다. 인코더와 디코더 라이선스가 별개인 것이 이 문제의 원인인 것 같습니다. 매우 저렴한 장치는 aptX도 지원한다고 표시되어 있지 않는 경우가 있습니다.

불행하게도 대부분 OS에서는 사용자 인터페이스에 지원하는 코덱을 표시하지 않습니다. 현재 사용 중인 코덱 정보는 안드로이드 버전 8 이상과 macOS에서만 표시됩니다. 이 경우에도 휴대폰/컴퓨터와 헤드폰에서 모두 지원하는 코덱만 표시됩니다.

그렇다면 장치가 지원하는 코덱 정보는 어떻게 알 수 있을까요? A2DP 협상 옵션이 포함된 트래픽을 캡처하고 분석하면 됩니다!

리눅스, macOS, 안드로이드에서 실행할 수 있습니다. 리눅스에서는 Wireshark나 hcidump, macOS에서는 Bluetooth Explorer, 안드로이드에서는 개발자 도구의 블루트스 HCI 덤프 저장 기능을 사용할 수 있습니다. Wireshark에서 분석할 수 있는 btsnoop 형식으로 저장됩니다.

메모: 올바른 덤프를 얻으려면 스마트폰/컴퓨터에서 연결 요청을 보내야 하며, 그 반대로는 불가능합니다! 헤드폰에서도 스마트폰이나 컴퓨터로 연결 요청을 보낼 수 있으며, 이 때에는 휴대폰에서 사용 가능한 코덱을 요청할 뿐이지 장치에서 지원하는 코덱 정보를 전송하지 않습니다. 올바른 덤프를 얻으려면 장치 페어링을 해제한 다음, 패킷 덤프를 시작하고 헤드폰과 스마트폰/컴퓨터를 다시 페어링해야 합니다.

다음 필터를 사용하여 관련된 트래픽만 볼 수 있습니다:

btavdtp.signal_id

이 필터를 사용하면 다음과 비슷한 패킷이 표시됩니다:

GetCapabilities 명령을 누르면 코덱의 자세한 정보를 알 수 있습니다.

Wireshark에서 모든 코덱 식별자를 지원하지 않기 때문에 일부 코덱은 직접 확인해야 합니다. 아래의 코덱 식별자 목록을 참조하십시오:

필수:
0x00 - SBC

선택:
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC

제조사 특정:
0xFF 0x004F 0x01   - aptX
0xFF 0x00D7 0x24   - aptX HD
0xFF 0x000A 0x02   - aptX Low Latency
0xFF 0x00D7 0x02   - aptX Low Latency
0xFF 0x000A 0x01   - FastStream
0xFF 0x012D 0xAA   - LDAC
0xFF 0x0075 0x0102 - 삼성 HD
0xFF 0x0075 0x0103 - 삼성 Scalable Codec
0xFF 0x053A 0x484C - Savitech LHDC

0xFF 0x000A 0x0104 - The CSR True Wireless Stereo v3 Codec ID for AAC
0xFF 0x000A 0x0105 - The CSR True Wireless Stereo v3 Codec ID for MP3
0xFF 0x000A 0x0106 - The CSR True Wireless Stereo v3 Codec ID for aptX 

다음 필터를 적용하여 장치에서 EDR 3 Mbps를 지원하는지 알 수 있습니다:

bthci_evt.code==0x0b

덤프를 직접 분석하기 어렵다면 다음의 자동 분석 서비스를 사용할 수 있습니다: btcodecs.valdikss.org.ru

간단하지만 유용한 Windows용 Bluetooth Tweaker 소프트웨어를 사용하면 지원하는 코덱과 사용 중인 코덱을 볼 수 있습니다.

리눅스를 사용한다면 BlueZ 패키지의 avinfo 유틸리티를 사용할 수 있습니다.

코덱 비교. 어느 코덱이 더 좋은가요?

각각 코덱은 장단점이 모두 있습니다.

aptX와 aptX HD는 인코더와 디코더를 변경하지 않는 한 변경할 수 없는 하드코딩된 프로필을 사용합니다. 스마트폰이나 헤드폰 제조사라고 해도 aptX의 비트 전송률이나 코딩 인자를 변경할 수 없습니다. 코덱의 소유자인 퀄컴은 레퍼런스 인코더 라이브러리를 라이선스 계약을 맺은 곳에 제공합니다. 이 점은 음질을 항상 미리 알 수 있다는 aptX의 장점이기도 합니다.

한편 SBC는 여러 인자를 조정할 수 있고, 유동적 비트 전송률을 지원(무선이 혼잡한 경우 인코더에서 비트풀을 감소시킬 수 있음)하며, 하드코딩된 프로필을 사용하지 않지만 2003년에 정의된 A2DP 표준에는 “중간 품질”과 “고품질” 추천값만 존재할 뿐입니다. “고품질”은 현재의 기준으로는 더 이상 고품질이 아니지만, 많은 블루투스 스택에서는 기술적인 제한이 없음에도 불구하고 “고품질” 프로필 이상의 인자를 사용할 수 없습니다.

Bluetooth SIG에서는 라이브러리 형태의 SBC 레퍼런스 인코더를 제공하지 않기 때문에 제조사에서 직접 구현해야 합니다.

이 점은 SBC의 약점이기도 합니다. 특정한 장치에서 나오는 음질을 미리 알기는 어렵습니다. SBC는 설정에 따라 저음질과 최고 음질 결과물을 생성할 수 있으나, 최고 음질은 블루투스 스택의 인위적인 제한을 비활성화하거나 우회하지 않으면 불가능합니다.

AAC의 상황은 애매합니다. 이론적으로는 코덱으로 인코딩한 결과물이 원음과 구분하기 어려워야 하나, 실제로는 SoundGuys 연구소에서 여러 안드로이드 장치에서 테스트해 본 결과에 의하면 그렇지 않았습니다. 이런 현상이 발생하는 이유로는 여러 휴대폰 칩셋에 내장된 하드웨어 인코더의 품질 문제로 추정됩니다. 애플 장치에서는 AAC를 사용하는 것을 추천하지만, 안드로이드 장치에서는 aptX/HD나 LDAC 쪽이 더 좋습니다.

대체 코덱을 지원하는 장치는 대개의 경우 품질이 좋은 편입니다. 싸구려 저품질 장치에 이러한 코덱을 지원하는 로열티를 낼 이유는 없기 때문입니다. 자체 실험 결과 고품질 하드웨어에서의 SBC의 음질은 상당히 좋았습니다.

원 저자는 특정 오디오를 브라우저에서 실시간으로 SBC, aptX, aptX HD로 인코딩하는 웹 서비스를 개발했습니다. 블루투스로 오디오를 전송하지 않고도 임의의 유선 헤드폰, 스피커에서 즐겨 듣는 곡을 사용하여 오디오 코덱을 시험해 볼 수 있습니다. 오디오 재생 중에 인코딩 인자를 변경할 수도 있습니다.

btcodecs.valdikss.org.ru/sbc-encoder

이 서비스는 BlueZ 프로젝트의 SBC 코딩 라이브러리와 ffmpeg의 libopenaptx를 사용하며, 웹 브라우저에서 사용할 수 있도록 C 언어에서 emscripten을 사용하여 WebAssembly와 자바스크립트로 컴파일됩니다. 대단하죠!

실제 작동하는 모습입니다:

Your browser does not support HTML5 video.

서로 다른 코덱에서 20 kHz 이상의 노이즈 레벨이 변경되는 것에 주목하십시오. 원본 MP3 파일에는 20 kHz 이상의 주파수가 저장되어 있지 않습니다.

코덱을 변경해 보고 원본, SBC 53 조인트 스테레오(일반적으로 자주 사용되는 표준 프로필), aptX, aptX HD 사이의 차이점을 들어 보십시오.

그래도 “헤드폰”에서 코덱 사이의 차이를 들을 수 있어요!

웹 서비스를 통해서 코덱의 차이를 들어 보지 않았다면 블루투스 헤드폰으로 음악을 들었을 때 차이를 느꼈다고 주장합니다. 불행히도 이것은 플라시보 효과가 아니라 실제 존재하는 차이지만, 코덱의 차이로 인해서 발생하는 차이는 아닙니다.

무선 리시버에 내장된 대부분의 블루투스 오디오 칩셋은 DSP(디지털 신호 프로세서)를 내장하고 있어서 소리를 강화(또는 변화)할 수 있는 이퀄라이저, 컴팬더(compander), 스테레오 익스텐더 기능을 구현합니다. 블루투스 하드웨어 제조사에서는 각각 코덱별로 DSP 설정을 변경할 수 있으며, 코덱을 변경할 때 청자가 코덱에 따른 음질 차이를 듣는다고 생각하는 것은 실제로는 서로 다른 DSP 설정에 의한 차이입니다.

일부 프리미엄 장치는 DSP 인자를 조절할 수 있는 소프트웨어를 지원하지만, 저렴한 헤드폰은 이러한 기능을 지원하지 않으며 사용자는 사운드 후처리 기능을 표준 도구만으로 끌 수 없습니다.

장치별 기능

A2DP 표준의 현재 버전에서는 오디오 스트림의 음량을 직접 조절하지 않고 AVRCP 프로토콜을 사용하여 특수 명령으로 출력 게인을 제어하는 절대 음량 제어(absolute volume control) 기능을 지원합니다. 헤드폰에서 음량을 변경했으나 휴대폰의 음량과 동기화되지 않는다면 헤드폰이나 휴대폰에서 이 기능을 지원하지 않는 것입니다. 이 경우에는 휴대폰에서는 항상 최대 음량으로 음악을 재생하고 헤드폰 단추로 음량을 조절하는 것을 추천합니다. 신호대 잡음비가 더 나을 것이며 음질이 높아야 합니다.

현실에서는 더 나쁜 경우도 존재합니다. RealForce OverDrive D1 헤드폰에서는 SBC에 강력한 컴팬더를 사용하기 때문에 음량을 높이면 조용한 소리의 음량도 같이 올라가지만 시끄러운 소리의 음량은 변하지 않습니다(신호가 압축됨). 그래서 컴퓨터 쪽의 음량을 절반 정도로 설정하여 압축 효과가 실질적으로 나타나지 않게 해야 합니다.

원 저자의 관찰 결과에 의하면 추가 코덱을 지원하는 모든 헤드폰에서는 절대 음량 제어 기능을 제공하며, 코덱 인증 절차의 일부로 포함되어 있을 것으로 추정합니다.

일부 헤드폰은 동시에 두 개의 장치에 연결할 수 있습니다. 컴퓨터에서 음악을 들으며 휴대폰에서 통화를 할 수 있는 것과 같은 상황을 지원합니다. 그러나 이런 상황에서는 대체 코덱이 비활성화되며 SBC만 사용됩니다.

AVDTP 1.3 지연 보고(Delay Reporting) 기능을 지원하는 헤드폰에서는 소리를 전송하는 장치에 지연 상황을 보고할 수 있습니다. 동영상을 볼 때 음악과 영상의 동기화를 조절하는 데 도움을 줄 수 있습니다. 만약 무선 혼선이 일어난다면 음성이 영상을 따라가지 못하는 것이 아니라 동영상 재생기에서 영상 재생이 느려져서 음성과 영상의 동기화를 다시 맞춥니다.

이 기능은 많은 헤드폰에서 지원하며, 안드로이드 9+, PulseAudio 12.0+가 설치된 리눅스에서 사용할 수 있습니다. 다른 OS에서의 지원은 알려져 있지 않습니다.

블루투스를 통한 전이중 통신. 음성 전송.

SCO(Synchronous Connection Oriented)와 확장된 버전 eSCO(Enhanced Synchronous Connection Oriented) 모드는 블루투스 음성 전송에 사용됩니다. 이 모드에서는 음성을 엄격한 순차적으로 전송할 수 있으며, 송신과 수신 속도는 대칭적이며, 패킷 수신 확인이나 재전송을 기다리지 않습니다. 무선 채널을 통한 오디오 전송 지연 시간을 줄여 주지만, 단위 시간당 전송되는 오디오 데이터의 양에 큰 제한을 두며 음질에 악영향을 줍니다.

이 모드를 사용할 때에는 마이크로 녹음된 음성과 헤드폰으로 전송되는 음성의 음질이 동일합니다.

데이터 그 자체의 전송은 HSP 프로필로 표준화되어 있으며, 이 프로필에서는 음량 제어 기능, 핸드셋 통화 시작 및 종료 등 여러 기능을 지원합니다.

불행히도 2019년 현재에도 블루투스 음성 전송 품질은 좋지 못하며 왜 Bluetooth SIG가 이 부분에 관심을 주지 않는지는 알려져 있지 않습니다.

CVSD

기본 음성 전송 코덱 CVSD는 2002년에 표준화되었으며, 모든 양방향 블루투스 장치에서 지원합니다. 일반적인 유선 전화 음질인 8 kHz 샘플링 레이트 오디오 전송을 지원합니다.

이 코덱으로 녹음한 예시입니다.

mSBC

추가 mSBC 코덱은 2009년에 표준화되었으며, 2010년에 해당 코덱을 사용하는 하드웨어 칩셋이 발매되기 시작했습니다. 다양한 장치에서 mSBC를 지원합니다.

이 코덱은 단독 코덱이 아닌 16 kHz, 모노, 비트풀 26으로 고정된 A2DP 표준의 SBC입니다.

이 코덱으로 녹음한 예시입니다.

CVSD보다는 더 낫지만 여전히 음질이 좋은 편은 아닙니다. 인터넷, 특히 게임 내에서 통신하려고 헤드폰을 사용한다면 게임의 소리도 16 kHz 샘플링 레이트로 전송되기 때문에 음질이 좋지 않게 들릴 것입니다.

FastStream

CSR은 SBC를 재사용하는 아이디어를 확장했습니다. SCO 프로토콜의 한계를 우회하고 비트 전송률을 높이기 위해서 양방향 전송이 가능한 SBC를 단방향 전송만 가능한 A2DP처럼 사용할 수 있는 기능을 개발했고, 이 기능의 이름을 “FastStream”이라고 붙였습니다.

FastStream은 스피커로 44.1 kHz나 48 kHz 샘플링 레이트, 212 kbps로 인코딩된 소리를 재생합니다. 마이크에서 녹음한 오디오는 16 kHz 샘플링 레이트, 72 kbps 비트 전송률(mSBC보다 약간 높은 수준)로 전송됩니다. 이러한 구성은 온라인 게임 내에서의 통신에 좀 더 유용합니다. 게임 소리와 다른 팀 구성원의 소리는 여전히 고음질로 들을 수 있습니다.

이 코덱으로 녹음한 예시 (+ 마이크에서 녹음한 오디오, mSBC와 동일).

이 방식은 매우 재미있는 핵이지만, A2DP 표준과는 모순된다는 문제가 있기 때문에 CSR의 일부 트랜스미터에서만 지원합니다. 이들은 블루투스 오디오 장치가 아닌 USB 오디오 카드처럼 작동합니다. 그러나 다른 블루투스 스택에서는 지원하지 않습니다. FastStream을 지원하는 헤드폰은 여러 종류가 있습니다.

현재 FastStream은 Pali Rohár가 작성한 리눅스 PulseAudio 패치로만 지원되는 것 같으며, 아직 메인라인에 통합되지는 않았습니다.

aptX Low Latency

놀랍게도 aptX Low Latency는 양방향 오디오를 지원합니다. FastStream과 비슷한 원리를 사용합니다.

이 코덱의 기능을 테스트해 볼 수 있는 방법은 없습니다. 아직까지 알려진 OS나 블루투스 스택 중에 Low Latency 디코딩을 지원하는 것은 없습니다.

블루투스 5, Classic과 Low Energy

블루투스 스펙과 버전을 둘러싼 여러 곳에서 혼동이 있습니다. 하나의 브랜드 아래에 두 가지의 서로 호환되지 않는 표준이 있으며, 이 둘은 서로 다른 목적으로 사용됩니다.

Bluetooth Classic과 Bluetooth Low Energy(LE, Bluetooth Smart라고도 알려짐)는 서로 호환성이 없는 두 종류의 블루투스 프로토콜입니다. Bluetooth High Speed라는 또 다른 프로토콜이 있지만 아직까지 찾아보기 어려우며 가정용 장치에는 사용되지 않습니다.

블루투스 4.0부터 표준안의 변경 사항은 Bluetooth Low Energy에 더 많은 초점을 맞추고 있으며, Classic 프로토콜의 개선 사항은 미미했습니다.

블루투스 4.2와 블루투스 5 사이의 차이점:

9 CHANGES FROM v4.2 TO 5.0
9.1 NEW FEATURES
Several new features are introduced in Bluetooth Core Specification 5.0 Release. The major areas of improvement are:

• Slot Availability Mask (SAM)
• 2 Msym/s PHY for LE
• LE Long Range
• High Duty Cycle Non-Connectable Advertising
• LE Advertising Extensions
• LE Channel Selection Algorithm #2

9.1.1 Features Added in CSA5 — Integrated in v5.0
• Higher Output Power

출처: www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=421043 (291쪽)

블루투스 5의 Classic에 영향을 주는 변경 사항은 단 한 가지 뿐입니다. SAM(Slot Availability Mask) 기능이 추가되었으며, 무선 주파수 공유에 좀 더 도움을 주는 목적을 가지고 있습니다. 다른 모든 변경 사항은 Bluetooth LE(및 Higher Output Power)에만 적용됩니다.

모든 오디오 장치에서는 Bluetooth Classic만 사용합니다. Bluetooth Low Energy 표준에는 오디오 전송 기능이 없기 때문에 헤드폰과 스피커를 연결할 수 없습니다. 고음질 오디오를 전송하는 A2DP 표준은 Bluetooth Classic으로만 작동하며, Bluetooth LE에는 같은 역할을 하는 것이 없습니다.

요약하자면, 블루투스 5를 지원하는 오디오 장치를 단지 새로운 버전의 프로토콜을 지원하기 때문에 사는 것은 의미가 없습니다. 오디오 전송은 블루투스 4.0/4.1/4.2와 완전히 동일합니다.

새 헤드폰을 출시하면서 블루투스 5 때문에 크기가 더 커지고 전력 소모량을 줄였다는 광고를 봤다면 해당 제조사에서도 블루투스 표준을 제대로 이해하지 못했거나 혼동을 주려는 의도임을 이해해야 합니다. 심지어는 블루투스 칩셋 제조사에서도 두 가지 표준을 혼동하며, 일부 블루투스 5 칩셋은 LE 부분만 블루투스 5를 사용하고 Classic에는 4.2를 사용하기도 합니다.

오디오 전송 지연

오디오 전송 지연(랙이라고도 함)은 여러 요소에 의해서 결정됩니다. 오디오 라이브러리, 블루투스 스택, 재생 장치 자체 버퍼의 크기, 코덱의 알고리즘적 지연 등이 있습니다.

SBC, aptX, aptX HD와 같은 간단한 코덱의 지연 시간은 3-6 ms 정도로 무시할 수 있는 정도로 짧은 편입니다. 그러나 AAC, LDAC와 같은 복잡한 코덱의 지연 시간은 귀로도 들을 수 있습니다. 44.1 kHz AAC의 알고리즘 지연은 60 ms, LDAC는 30 ms 정도입니다. LDAC의 지연 시간은 소스 코드 분석을 통해서 계산했으나, 실제로 큰 차이는 없을 것입니다.

총 지연 시간은 재생 장치, 칩셋, 버퍼에 크게 의존합니다. 테스트하는 동안 여러 다른 장치에서 SBC 코덱을 사용할 때 150 ms부터 250 ms까지의 지연 시간을 측정할 수 있었습니다. aptX, AAC, LDAC 추가 코덱을 지원하는 장치에서 고품질 구성 요소를 사용하고 버퍼 크기를 작게 설정했다면 대개의 경우 다음 지연을 예상할 수 있습니다:

• SBC: 150-250 ms
• aptX: 130-180 ms
• AAC: 190-240 ms
• LDAC: 160-210 ms

마지막으로 한 번 짚고 지나갑니다. aptX Low Latency는 여러 운영 체제에서 지원하지 않기 때문에 저지연 모드를 사용하려면 트랜스미터+리시버나 트랜스미터+헤드폰/스피커 번들을 사용해야 하며, 모든 장치에서 이 코덱을 지원해야 합니다.

인증, 로고, 장치의 문제

고품질 오디오 장치와 싸구려 물건을 어떻게 구분할 수 있을까요? 일단 외관부터 봅시다!

싸구려 중국제 헤드폰, 스피커, 리시버의 특징은 다음과 같습니다:

1. 포장 상자와 장치 그 자체에 “Bluetooth” 언급이 없으며, “무선”이나 “BT” 등만 있음
2. 포장 상자나 장치에 블루투스 로고 가 없음
3. 파란색 LED가 없음

이러한 특징이 보이지 않는다면 장치가 인증받지 않았음을 의미하며, 장치 품질에 대해서 보증할 수 없음을 의미합니다. 예를 들어 Bluetooth SIG에서 인증받지 않은 Bluedio 헤드폰은 A2DP 표준을 완전히 준수하지 않습니다. 아마도 인증 절차를 통과할 수 없었을 것입니다.

이제 일부 장치와 포장 박스를 알아 봅시다:

이 장치는 모두 인증받지 않았습니다. 설명서에 로고와 “블루투스” 이름이 있기는 하지만, 실제로 이 로고는 장치나 포장 박스에 있어야 합니다.

만약 블루투스 헤드폰이나 스피커에서 나오는 안내 음성이 “Ze bluetooth dewise is connecteda successfulle”처럼 왜곡되어 있다면 장치의 품질에 대해서 큰 기대를 하지 마십시오.

결론

블루투스는 유선 휴대폰을 완전히 대체할 수 있을까요? 아마도요. 그러나 저품질 음성 통화, 게임 등에 문제가 될 수 있는 음악 전송 지연 시간, 라이선스 비용이 필요하기 때문에 스마트폰과 헤드폰 가격을 올리는 데 기여하는 독점 코덱을 감안해야 합니다.

대체 코덱은 매우 활발히 마케팅되고 있습니다. aptX와 LDAC는 “오래되고 저음질”인 SBC의 대체품으로 광고되고 있지만 실제로 SBC는 생각하는 것만큼 나쁘지 않습니다.

블루투스 스택에서 SBC에 적용하는 인위적인 제한을 우회하면 aptX HD와 비슷한 음질을 낼 수 있습니다. 원 저자는 LineageOS 펌웨어에 패치를 제출했습니다: Modifying Bluetooth stack to improve the sound on headphones without AAC, aptX and LDAC codecs

코덱에 대한 더 많은 정보를 보려면 SoundGuys 및 SoundExpert 웹 사이트를 참조하십시오.

보너스: SBC 레퍼런스 인코더, A2DP 비트스트림 정보 및 테스트 파일입니다. 이 파일은 블루투스 웹 사이트에 게시되어 있었으나 현재는 Bluetooth SIG 회원만 접근할 수 있습니다.