100유로 내에서 구할 수 있는 5G 지원 휴대폰도 하나 필요했고, 마침 미디어텍 5G 휴대폰도 있었다가 없어진 상태에서 삼성 SCR01이 레이더에 들어왔다. 문제는 일본-독일 직배송이나 배대지가 일본-한국 배대지보다 훨씬 비싼 탓에 SCR01 구매를 꽤 오랫동안 미루어 왔고, 한국에 갔다 온 김에 SCR01도 사서 돌아왔다. 여러 한국 사이트에서 SCR01 구매처나 기본적인 설정 방법에 대해서는 많이 알려져 있기 때문에 이 글에서는 다른 곳에서 찾아보기 힘든 것들 위주로 SCR01을 뜯어 볼 생각이다.
5G SA 테스트
한국 통신사들의 28 GHz 맥거핀에 묻혀서 5G SA는 등한시되고 있다. 커뮤니케이션 모드가 일반(ST)과 플러스 지역(+A)으로 나뉘어 있는데, AUG2 펌웨어 기준 LTE에서의 UECapabilityInformation을 비교해 봤을 때 NR Band n28이 활성화되느냐 아니냐 차이가 있는 것 같았다. 한국이라면 NR n78만 있기 때문에 상관이 없지만 다른 밴드는 통수를 당할 수도 있는 것 같다.
한국이라면 전환할 필요가 없을 듯
MediaTek 유틸리티 사용법
액티비티 런처를 설치하면 시스템에 설치된 모든 APK에서 제공하는 액티비티를 보거나 실행할 수 있으며, 미디어텍에서 제공하는 시스템 앱은 꽤 다수가 잘렸거나 삼성 앱으로 대체되었지만 다행히도 Control Plane 디버깅에 유용한 DebugLoggerUI는 잘리지 않았다. MainActivity를 실행하면 로그 제어 화면이 나오고, 휴대폰 내부 저장소에 저장된 로그는 나중에 빼내서 미디어텍 ELT를 통해서 볼 수 있다. ELT를 구하는 방법은 이 글에서는 설명하지 않겠다. 아 물론 *#9090# -> SilentLog는 다른 삼성 휴대폰처럼 그대로 살아 있다.
땡큐 삼성
또 다른 맥거핀 GSM 활성화?
안 되더라. 별의별 방법을 써 봤는데 대역 해금에는 실패. 모뎀 테스트 메뉴에서 밴드 활성화 메뉴를 들어가 봐도 GSM이나 3G 자체는 보이지 않아서 포기했다.
같이 보기
SCR-01 펌웨어 및 정보 총정리: 글 중간에 지금까지의 모든 SCR01 펌웨어가 올라와 있는 box.com 링크가 있다. Samfirm이나 Frija로 펌웨어를 다운로드하려면 모델명 SCR01/CSC KDI를 입력하면 된다. 글 끝에서는 다운로드 모드 진입 방법을 소개하고 있다.
[스압]하늘목장님 추천기기 SCR-01(SM-H412J) 사용기/5G 활성화 팁: SCR01 분해 사진, 서비스 모드 접근 방법(삼성 계산기 설치 후 “(+30012012732+” 입력 후 *#0011# -> 햄버거 메뉴에서 Back, Key Input -> Q, 이후 대기), 5G Allow List 비활성화 및 SA 활성화.
한글 인코딩에 관한 조합형완성형 논쟁은 유니코드에서 완성형과 조합형 모두를 수용하는 방식으로 종결되었지만, 한글 글꼴 구현에는 조합형 완성형 논쟁의 잔재가 아직까지도 남아 있고 글꼴을 갖다 써야 하는 곳에 따라서 과거의 조합형 글꼴을 아직도 써야 하는 경우가 생길 수도 있다. 당장 일부 한글 글꼴이 완성형 2350자 이외의 글자에 대한 글리프가 없어서 해당 글자를 입력하면 깨지는 것도 이 시기의 잔재이다. 디스플레이 화소 수가 적고 메모리 공간이 KB 대에서 노는 임베디드 환경이라면 조합형 글꼴(조합형 인코딩이 아님!)로 한글을 표시하는 게 유리할 수 있다. 한글 낱자가 들어오면 그것들을 나눗셈과 나머지 연산으로 자소 단위로 분해하고 수백개의 글리프 중 최대 3개를 OR 조합해서 표시하는 게 2350/11172자 모두의 글리프를 들고 있다가 표시하는 것보다 데이터 양은 더 적게 필요하다. 그 동안 도스 시절의 한글 바이오스나 컴퓨터 역사 초기의 한글 구현을 분석하면서 알게 되었던 각종 조합형 글꼴 구성을 이 글에서 정리하고자 한다.
8x4x4 조합형 글꼴
상당히 많은 곳에서 쓰이고 있는 조합형 글꼴 구성 방식이다. 원리는 지금도 잘 알려져 있고 명세를 구하는 것도 어렵지 않다(링크). 초성 8벌, 중성 4벌, 종성 4벌에 해당하는 글리프를 미리 만들어 두고 자모의 종류에 따라서 서로 다른 글리프를 사용한다. 8x4x4 조합형의 구현체는 많은 곳에서 찾을 수 있기 때문에 해당 조합 방식의 글꼴을 사용하는 곳과 추출하는 방법만을 여기에서 소개한다.
글꼴 통합 변환기(링크): 8x4x4 조합형 글꼴을 BDF나 TTF 형식으로 변환할 수 있다.
한글을 자유롭게 1.54(링크): 실행 파일 한 개로 구성된 한글 바이오스이다. 실행 파일 자체는 DIET 패커로 압축되어 있기 때문에 일단 압축을 풀어 주어야 비트맵을 추출할 수 있다. 글꼴은 한 종류만 들어가 있다.
한글 1.2, 1.5: 이 시기의 한글은 HFT 글꼴을 사용하지 않았고 프린터용 PFT와 화면용 SFT 글꼴을 사용했다. SFT 파일 형식은 헤더 32바이트만 잘라내면 나머지는 바이너리 비트맵이다.
태백한글 1.01, 1.5, 2.0, 3.0, 3.5: 글꼴은 전 버전 모두 FNT 확장자를 사용하며, 바이너리 비트맵이기 때문에 글꼴 통합 변환기에서 처리가 가능하다. 단 태백한글 3.0 이후의 24×24 등 16×16 초과 글꼴은 글꼴 통합 변환기로는 처리가 불가능하다.
미니 한글 라이브러리: 소스 코드의 FONT.C 파일에 8x4x4 비트맵이 하드코딩되어 있다.
HT: 실행 파일은 LZEXE로 압축되어 있다. 파일의 압축을 풀면 8x4x4 비트맵이 내장되어 있다.
8x4x4 조합형에서 초성 글리프가 두 벌 더 들어간 형태이다. 중성과 종성 조합 규칙은 8x4x4와 동일하나 초성 조합 규칙은 살짝 다르다. 글꼴 통합 변환기의 hanlib/Table8x4x4.c 파일과 hanlib/Table10x4x4.c 파일을 비교하면서 보면 이해할 수 있다. 아래에 있는 두 종류의 10x4x4 조합형 글꼴은 높이 문제 때문에 그대로 통합 변환기에 전달할 수는 없으며 적절하게 높이를 조정해 줘야 한다.
GSVIP(금성 한글 BIOS) 3.52: 글꼴은 GSF 확장자를 사용한다. 용량을 줄이기 위해서인지 16×16 글꼴임에도 불구하고 초성, 중성, 종성의 세로 높이는 각각 벌마다 일정하지 않다. 아래 그림은 의도적으로 16×16 사각형에 모든 벌을 출력하도록 설정했으나, 초성과 종성은 세로 출력 위치를 조정해 주어야 제대로 된 글자를 볼 수 있다.
HECON(대우통신 한글 BIOS) 4.00.20: HECON.EXE 파일에 내장된 글꼴도 이 쪽에 속하지만 역시 높이가 일정하지 않다. HE24.SYS 파일의 24×24 한글 글꼴은 12x2x4 조합을 사용한다.
GSVIP 한글 글꼴 예제
14x6x4 조합형 글꼴
아직까지 이 조합형을 사용하는 곳은 삼보컴퓨터 계열밖에 보지 못했다. 초성 벌 수가 상당히 많이 들어가 있다는 것이 특징이며, 중성은 x6이라고 쓰기는 했으나 일부 중성만 6벌이 들어가 있고 대부분 중성은 3벌만 들어가 있다. 아직까지 정확한 조합 방법을 찾지는 못했다. 특이하게 아래아가 중성 조합 중에 들어가 있다.
TGHP 1.20: HAN16.FNT와 HAN24.FNT에 각각 16×16, 24×24 글꼴이 들어가 있다. 24×24 글꼴은 초성 조합 벌 수가 13이나 12벌인 경우가 있다.
독일은 1981년 헬무트 슈미트 총리 집권 시기에 향후 30년간 전 (서독) 국토에 광 케이블을 설치하려고 계획했으나, 후임인 헬무트 콜 총리 당시 예산을 아낀다는 핑계를 대고 광 케이블 설치 계획을 취소하고 케이블 TV로 바꿔 버리는 바람에 지금도 유럽에서 FTTx 보급률이 낮은 편이고 닳고 닳은 전화선과 케이블 인터넷을 어떻게든 우려먹고 있다. VDSL Vectoring으로 250 Mbps를 뽑아내는 똥꼬쑈! 그래서 독일에 도착해서 인터넷을 신청하려고 하면 DSL이냐 케이블이냐 둘 중 하나가 대부분이고, FTTH는 들어온다면 로또를 맞았다고 생각하면 된다. 유선 인터넷 회사에서는 보통 DSL/케이블 모뎀+Wi-Fi 라우터 기능을 하는 장비를 (대여해) 주거나 사용자가 직접 모뎀을 설치할 수 있다. 비록 통신사 쪽에서는 좋아하지 않는 눈치긴 하지만 2016년 8월 1일에 법제화되었다(키워드: Routerfreiheit/Routerzwang). 한국에서 ipTIME 같은 걸 들고 왔다고 해도 그대로 쓸 수 없고 쓸 필요도 없는 게 이것 때문이다. 인터넷이 들어오는 방식이 다르기 때문.
내가 독일에 처음 왔을 때에는 DSL 모뎀+OpenWRT 설치가 가능한 Wi-Fi 공유기를 생각하고 있었으나 이걸 하고 싶어도 방법이 거의 없었다. DSL 모뎀만 따로 사려고 하니까 잘 찾지를 않는 건지 오프라인상으로는 구하기도 어려웠고, 그렇다고 통신사에서 제공하는 공유기를 쓰고 싶지는 않아서 2015년 당시의 DSL 최신 기종인 FritzBox 7490(출시는 2013년)을 사 버렸다. (협찬받은 거 그런 거 없음)
FritzBox 7490
나중에 알게 된 사실이긴 하지만, Ubiquity나 MikroTik 같은 기업용 딱지 붙은 거 빼고 가정용 딱지 붙은 것 중에서는 순정 소프트웨어 상태가 최고라고 할 수 있다. 기본 제공하는 기능이 단순히 DSL 모뎀+Wi-Fi뿐만 아니라 VoIP 게이트웨이(DECT, ISDN/POTS, SIP 전화 붙이기 가능), 간이 NAS(USB 저장 장치 연결 필요), IPSec VPN, DNS over TLS 등 하이엔드 공유기 라인업에서나 볼 수 있는 것들이 기본 내장되어 있다. 집에 설치해 둔 필립스 Hue 스마트 전구를 Home Assistant와 ZigBee 모듈을 사용해서 별도의 Hue 브리지 없이 사용하고 있는데, 일부러 스마트 홈을 인트라넷에 가둬 뒀기 때문에 접속하려면 VPN을 타고 가야만 하도록 만들어 놨다. USB 포트에 LTE 모뎀을 연결하면 DSL이나 케이블이 죽었을 때 자동으로 LTE로 전환하는 기능도 있고, 인터넷 이전이나 신규 설치가 꽤 오래 걸리는 독일 특성상 이걸 잘 써먹기도 했다. DECT 베이스 스테이션 기능을 사용해서 VoIP 서비스를 무선 전화기로 곧바로 사용할 수도 있다. 이미 독일에서는 2020년 Deutsche Telekom이 ISDN 공중 전화망을 다 걷어내 버려서 집전화가 거의 VoIP 기반으로 굴러 가고 있다는 점도 감안해야겠지만.
WPA3 지원IPSec VPN 지원DECT 베이스 스테이션 지원
단순히 기능뿐만 아니라 보안에도 신경을 많이 쓰고 있다. 칩셋 벤더의 역량에 따라 다르긴 하지만 주어진 한계 내에서는 리눅스 커널 버전을 잘 따라가고 있다. FritzBox 7490이 출시 당시에는 리눅스 커널 2.6.36을 사용했지만 지금은 3.10/4.4(Wi-Fi 서브시스템)까지 올라가 있다. 심지어 GPL 아카이브에는 가정용 공유기에서는 쉽게 찾아보기 힘든 AppArmor까지 적용해 둔 걸 확인할 수도 있다. 그리고 출시된 지 7년이 지난 모델에 WPA3 암호화를 제공해 주는 것도 포인트. 외부에서 라우터 설정 페이지에 접근할 때 DDNS 도메인으로 Let’s Encrypt 인증서를 찍는 것도 다른 공유기에서는 찾아보기 힘든 기능 중 하나다. AVM 홈페이지에서는 구형 모델의 기술 지원 중단 날짜를 아예 게시해 두었고, GPL을 준수하는 방법을 한동안 갈팡질팡하던 국내회사와는 다르게 펌웨어 버전별로 오픈소스 소스 코드를 잘 공개하고 있다. 몇 술 더 떠서 펌웨어 업데이트에서 보안 업데이트 내역만 따로 뽑아서 고지하거나, 각종 보안 문제에 어떻게 영향을 받는지를 별도로 공지하는 회사? 얼마나 있나? 2016년에 케이블 모뎀에 들어가는 DOCSIS CA 인증서 배포 문제 때문에 CA 인증서를 한 번 갈아엎은 적도 있었지만 이것도 보안 공지에 명시되어 있다.
MyFritz: Let’s Encrypt 인증서를 찍어 주는 기능 기본 내장
대신 이렇게 순정 펌웨어에 기능이 상당히 많이 들어가 있다 보니 도리어 OpenWRT를 올리기는 까다로운 편에 속하고 올리려는 시도도 적은 편이다. 실제로 OpenWRT 위키에 있는 AVM 장치도 대부분 지원이 중단된 모델 위주고, 현역이라고 할 수 있는 모델은 하드웨어 구조가 상대적으로 간단한 FritzBox 4020, 4040, 7530 정도이다(DSL은 OpenWRT에서 미지원). 지금 쓰고 있는 7490도 하드웨어 구조가 특이한 편에 속한데, 메인+DSL SoC로 Lantiq VRX288을 사용하는 것 자체는 평범하다. 그러나 Wi-Fi 칩셋으로 Lantiq WAV 시리즈를 사용하는 게 아니라 그 자체로도 공유기를 만들 수 있는 QCA9558+PCIe로 연결되는 QCA9880을 사용하고 있다. 한 술 더 떠서 USB 3.0 포트 두 개는 SoC가 아니라 PCIe로 연결해 둔 uPD720202 칩셋으로 돌아간다. 최신형 802.11ax 지원 6660 Cable은 그나마 구조가 정상적인 인텔 Puma 7+MaxLinear DOCSIS 프론트엔드+WAV600 구성이긴 하지만.
AVM의 주요 시장이 독일을 비롯한 유럽이고, 주력 모델이 DSL/케이블 내장형이라서 한국에서 사용하기에는 불필요하게 가격을 상승시키는 원인일 뿐이라서 이걸 공유기로 쓰려고 한국에서 굳이 구해다 쓰는 사람은 아직까지는 많이 보지 못한 것 같다. 심지어 Home Assistant 한국어 번역 프로젝트에서는 이걸 “독일통신사“로 착각하기도 했다. 7490 독일판도 한동안은 펌웨어 언어가 독일어만 지원했고 영어를 비롯한 타 언어 지원은 7.21 들어서야 추가되었다. 한국에서 이걸 쓴다면 기능을 100% 다 살릴 수는 없지만 방법이 아주 없는 것은 아니다.
독일에서 주력으로 팔리고 있는 모델은 DSL 모델과 케이블 모델이고, 유선 통신사에서 주는 모뎀+공유기도 대부분 DSL/케이블+Wi-Fi 내장형이기 때문에 한국산 공유기처럼 이더넷 포트만 달려 있는 모델은 주력 제품이 아니다. LTE 지원 모델 중 6890은 DSL+LTE, 6850과 6820은 LTE만 지원한다. 독일에는 FTTH가 되는 집은 로또 당첨이기 때문에 광 케이블 모델이 있기는 하지만(5490, 5491) 이건 일반 시장용으로는 풀지 않았고 ISP에 OEM으로만 들어갔다. 4040과 4020은 한국 공유기와 비슷하게 이더넷만 사용하지만 독일 유선 인터넷에 모뎀 단독으로 쓰는 환경은 거의 없기 때문에 이것도 주력 제품과는 거리가 있다.
그래서 한국에서 FritzBox를 사용하고 싶다면 차라리 DSL 모델이 가격 할인할 때 사는 것이 지원 받기에 그나마 나은 옵션이다. 독일 내에서 주력 상품이라서 펌웨어 업데이트도 잘 되고 있고, 내장 DSL 모뎀은 비활성화해 두고 기존 인터넷과 연결해서 사용하는 것도 가능하기 때문이다. 대신 이 경우 LAN 포트 하나를 희생해야 하지만. 결정적으로 DSL 모델은 리눅스 셸에 접근할 수 있지만 케이블 모델은 DOCSIS 보안 문제 때문에 셸 접근이 일반적으로는 막혀 있다.
FritzBox의 DSL 모뎀을 비활성화하고 공유기처럼 쓰기
만약 한국에서 DSL 모뎀으로 사용해야 한다면 Annex 설정에 주의해야 한다. 독일은 공중 전화망으로 ISDN을 활발하게 사용한 나라인데, ISDN은 아날로그 집전화보다 대역을 더 넓게 사용했다. 그래서 ADSL/VDSL을 도입할 때에도 ISDN 주파수 대역을 피해야 했기 때문에 업링크 주파수 대역이 다른 나라보다 고주파에서 시작한다. 아래 그림과 같이 주파수 대역을 Annex A, Annex B와 같이 구별한다. 독일은 Annex B를 사용하고 있고 나머지는 대부분 Annex A를 사용하고 있다. Annex 변경은 대부분 기종이 지원하기는 하지만 구형 독일판 모델은 Annex B에 고정되어 있을 수도 있으니 이걸 조심해야 한다. 그리고 PPP 인증 정보도 옮겨 심어야 하는데 기존 모뎀에서 복사하거나 통신사에 문의하는 방법밖에는 없다.
반면 케이블 모뎀의 경우 골때리는 문제가 몇 가지 있다. DOCSIS 3.0까지는 미국식 DOCSIS와 유럽식 EuroDOCSIS가 나뉘어 있고, FritzBox가 공식적으로 지원하는 것은 EuroDOCSIS이다. 둘 사이의 가장 큰 차이점은 다운링크 채널 대역폭이 DOCSIS는 6 MHz, EuroDOCSIS는 8 MHz이다. 이외에도 주파수 특성이 다른 것이 있지만 자세한 기술적인 정보는 생략. NTSC와 PAL 시절 채널 대역폭이 달랐던 것이 케이블 방송에도 그대로 적용되었고 이게 DOCSIS까지 타고 올라온 것이기 때문이다. DOCSIS 3.1 지원 모델은 글 쓰는 시점에서는 6660 Cable이 유일하다. EuroDOCSIS 3.0만 지원하는 모델이라면 한국 DOCSIS 망 신호를 잡지 못할 수도 있다. 여기에 더해서 DOCSIS 가입자 인증 문제가 있다. DOCSIS 인증은 케이블 모뎀의 MAC 주소와 장치별 인증서로 돌아가는데, MAC 주소와 장치별 인증서는 항상 1:1로 대응된다. 이론적으로는 통신사 고객센터에 MAC 주소를 불러 주고 이걸로 바꿔 달라고 할 수도 있지만, 기존 케이블 모뎀의 인증서와 MAC 주소를 복제하는 방법도 있다. 자세한 기술적인 방법은 케이블 모뎀마다 다르므로 생략. AVM의 기존 모델이 대부분 EuroDOCSIS 기반이고 미국에서 주력으로 팔렸던 적도 없었기 때문에 한국 CMTS에는 AVM의 인증서가 설치되어 있지 않을 수도 있다. 게다가 AVM은 2016년 DOCSIS 보안 취약점 사건 이후로 케이블 모뎀 내장형 FritzBox의 UART 사용 및 셸 진입을 아예 막아 버렸다. 일단은 이걸 뚫어야 DOCSIS 인증서를 심을 수 있기 때문에 기술적으로 자신이 없다면 안 하는 것을 추천한다.
VoIP 게이트웨이도 지원하기 때문에 이론적으로는 한국 통신사의 SIP 서버에 붙여서 쓸 수도 있지만 이건 아무도 시도해 보지 않았다. 게다가 SIP 인증 정보를 구하는 것부터가 일일 수도 있기 때문에 일단 그것부터 시작해야 FritzBox의 VoIP 기능을 한국에서 살릴 수 있을 것이다. 그리고 DECT 전화기를 사용한다면 주파수에 주의해야 한다. 독일에서 사용하는 DECT 주파수는 1880-1900 MHz고 FritzBox도 여기에 맞춰져 있다. 그러나 한국 DECT 주파수는 완전 갈라파고스인 1787 MHz에서 놀기 때문에 FritzBox에 한국 디지털 무선전화기를 붙일 수는 없다. 어차피 FritzBox가 SIP 서버로도 작동하기 때문에 SIP 다이얼러 앱을 사용하면 되므로 상관은 크게 없지만.
독일에서 좋든 싫든 FritzBox를 써 보게 되더라도 소프트웨어 품질은 생각한 것보다 상당히 좋을 수도 있다는 걸 생각해 봤으면 좋겠다.
이 글은 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개의 시분할 슬롯을 점유합니다.
한개의 장치에서 5개의 슬롯을 사용하고 다른 장치에서 1개의 슬롯을 사용할 때의(DH5/DH1) 전송 다이어그램
시분할 원칙에 의해서, 하나의 패킷을 전송한 후 두 번째 장치에서 아무 것도 전송하지 않았거나 작은 패킷을 전송했다면 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의 최신 버전에서는 작동함). 오디오를 들을 수 없다면 파일을 다운로드해서 직접 재생해 보십시오.
ZZ Top — Sharp Dressed Man
스펙트로그램에서 전환하는 순간을 볼 수 있습니다. SBC 코덱에서는 17.5 kHz 이상의 고주파 대역을 주기적으로 잘라내며, 20 kHz 이상의 대역에는 비트를 할당하지 않습니다. 스펙트로그램은 클릭해서 확대할 수 있습니다(1.7 MB).
원 저자는 이 곡의 원본과 SBC 인코딩된 것을 구분할 수 없다고 밝혔습니다.
이제 또 다른 것을 알아봅시다. 비트풀 값을 37로 변경하여 삼성 기어 아이콘X의 음질을 시뮬레이션해 보겠습니다(위쪽: 원본 스트림, 아래쪽: SBC 239 kbps, 오디오 인코딩: FLAC).
Mindless Self Indulgence — Witness
원 저자는 탁탁거리는 소리, 작은 스테레오 효과 및 고주파 대역 보컬에서 불쾌한 치찰음을 들을 수 있었습니다.
정리하자면 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 수준의 코덱에서는 이 방식에 큰 오류가 없습니다.
신호 차이의 제곱 평균 제곱근(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.
소니에서 개발하고 활발하게 밀어 주고 있는 “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에서도 지원하기는 하지만 매우 드뭅니다.
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
간단하지만 유용한 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로 인코딩하는 웹 서비스를 개발했습니다. 블루투스로 오디오를 전송하지 않고도 임의의 유선 헤드폰, 스피커에서 즐겨 듣는 곡을 사용하여 오디오 코덱을 시험해 볼 수 있습니다. 오디오 재생 중에 인코딩 인자를 변경할 수도 있습니다.
이 서비스는 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 설정에 의한 차이입니다.
CSR/퀄컴 칩셋의 Kalimba 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 샘플링 레이트 오디오 전송을 지원합니다.
CVSD보다는 더 낫지만 여전히 음질이 좋은 편은 아닙니다. 인터넷, 특히 게임 내에서 통신하려고 헤드폰을 사용한다면 게임의 소리도 16 kHz 샘플링 레이트로 전송되기 때문에 음질이 좋지 않게 들릴 것입니다.
FastStream
CSR은 SBC를 재사용하는 아이디어를 확장했습니다. SCO 프로토콜의 한계를 우회하고 비트 전송률을 높이기 위해서 양방향 전송이 가능한 SBC를 단방향 전송만 가능한 A2DP처럼 사용할 수 있는 기능을 개발했고, 이 기능의 이름을 “FastStream”이라고 붙였습니다.
FastStream은 스피커로 44.1 kHz나 48 kHz 샘플링 레이트, 212 kbps로 인코딩된 소리를 재생합니다. 마이크에서 녹음한 오디오는 16 kHz 샘플링 레이트, 72 kbps 비트 전송률(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
블루투스 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는 여러 운영 체제에서 지원하지 않기 때문에 저지연 모드를 사용하려면 트랜스미터+리시버나 트랜스미터+헤드폰/스피커 번들을 사용해야 하며, 모든 장치에서 이 코덱을 지원해야 합니다.
인증, 로고, 장치의 문제
고품질 오디오 장치와 싸구려 물건을 어떻게 구분할 수 있을까요? 일단 외관부터 봅시다!
싸구려 중국제 헤드폰, 스피커, 리시버의 특징은 다음과 같습니다:
포장 상자와 장치 그 자체에 “Bluetooth” 언급이 없으며, “무선”이나 “BT” 등만 있음
포장 상자나 장치에 블루투스 로고 가 없음
파란색 LED가 없음
이러한 특징이 보이지 않는다면 장치가 인증받지 않았음을 의미하며, 장치 품질에 대해서 보증할 수 없음을 의미합니다. 예를 들어 Bluetooth SIG에서 인증받지 않은 Bluedio 헤드폰은 A2DP 표준을 완전히 준수하지 않습니다. 아마도 인증 절차를 통과할 수 없었을 것입니다.
이제 일부 장치와 포장 박스를 알아 봅시다:
이 장치는 모두 인증받지 않았습니다. 설명서에 로고와 “블루투스” 이름이 있기는 하지만, 실제로 이 로고는 장치나 포장 박스에 있어야 합니다.
만약 블루투스 헤드폰이나 스피커에서 나오는 안내 음성이 “Ze bluetooth dewise is connecteda successfulle”처럼 왜곡되어 있다면 장치의 품질에 대해서 큰 기대를 하지 마십시오.
결론
블루투스는 유선 휴대폰을 완전히 대체할 수 있을까요? 아마도요. 그러나 저품질 음성 통화, 게임 등에 문제가 될 수 있는 음악 전송 지연 시간, 라이선스 비용이 필요하기 때문에 스마트폰과 헤드폰 가격을 올리는 데 기여하는 독점 코덱을 감안해야 합니다.
대체 코덱은 매우 활발히 마케팅되고 있습니다. aptX와 LDAC는 “오래되고 저음질”인 SBC의 대체품으로 광고되고 있지만 실제로 SBC는 생각하는 것만큼 나쁘지 않습니다.
HP Microserver Gen8은 시스템 칩셋으로 인텔 C204를 사용하고, 기본적으로 하드 베이에서 나온 SFF-8087 케이블이 인텔 C204의 SATA 컨트롤러에 연결되어 있다. 그래서 0, 1번 베이만 SATA 6Gbps를 지원하기 때문에 PCIe 슬롯에다가 SAS HBA를 붙여서 모든 베이에서 6Gbps를 사용하도록 하는 개조를 자주 당하고는 한다. ZFS 같은 소프트웨어 RAID를 사용할 거라면 굳이 하드웨어 RAID 카드를 붙일 필요가 없어서 IT 모드로 플래싱할 수 있는 캐시 안 달린 RAID 카드를 사용하기도 한다.
LSI(Avago를 거쳐서 Broadcom에 인수됨) RAID/HBA 카드는 SAS 계열에서 본좌 중 하나로 취급된다. LSI는 자체적으로 카드를 만들어서 팔 뿐만 아니라 서버 제조사에 OEM으로도 칩셋을 납품한다. LSI 버전 리테일 카드보다 OEM 버전 카드가 더 싸긴 한데, OEM 버전 카드는 LSI 버전보다 최신 펌웨어가 더 늦게 올라오거나 IR/IT 모드 펌웨어 중 하나마 올라오기도 한다. LSI SAS 칩셋과 카드 정보를 보려면 serverthehome에 있는 정보를 참조하면 된다. 덕분에 2cpu에서 인기 있었던 하드웨어가 IBM M1015인데, 이건 그냥 LSI 펌웨어를 강제로 밀어 넣으면 LSI 카드로 변신하고 IR/IT 모드 전환도 자유롭기 때문이다. 아직까지 국내에 후지쯔 D2607 카드로 시도해 보았다는 사람은 안 보이는데, 사실 후지쯔 카드의 SBR 구조가 다른 LSI 칩셋 카드와는 달라서 2016년에서야 성공했다는 블로그 글이 나왔다. 독일 이베이를 눈팅하다가 D2607이 꽤 싸게 풀린 걸 하나 낚아채서 이걸 시도해 보았다.
martan.st에 의하면 후지쯔 카드의 SBR은 0x12번째 바이트가 다른 LSI 카드와는 살짝 달라서, 다른 회사의 SBR을 그대로 밀어 넣으면 2개의 SFF-8087 포트 중 하나만 인식하는 경우가 생긴다. serverthehome에 올라온 글에 의하면, D2607 카드에는 A11과 A21 리비전이 있는데 문제의 0x12번째 바이트가 A11과 A21 리비전끼리도 서로 달라서(A11: 0x04, A21: 0x00) IT 모드로 플래싱할 때에도 하드웨어 리비전을 맞춰서 플래싱해야 한다. 내가 받은 카드도 A21 리비전이라서 D2607-A21용 SBR을 구해야 했다.
준비물은 UEFI 부팅 가능한 보드, D2607 카드와 포맷해도 상관 없는 USB 메모리다. Microserver Gen8은 UEFI를 지원하지 않지만, marcan.st 블로그에서는 sas2flash의 UEFI 버전을 수정해서 Mfg Page 2 validation을 건너뛰도록 만들어 놨기 때문이다. sas2flash의 DOS 버전의 같은 부분을 수정하면 UEFI 부팅 가능한 보드가 없어도 되지만, 아직까지 사람들이 거기까지는 시도해 보지 않은 것 같다. lime-technology 사이트에 A21과 A11 리비전용 SBR, sas2flash, IT 모드 펌웨어를 모아 놓은 압축 파일을 누군가가 올려 두었다. Rufus로 DOS 부팅용 USB를 만든 다음 이 파일을 USB 메모리의 루트에 압축을 풀어 놓으면 된다.
명령을 내려서 RAID 카드의 SAS 주소를 기록해 둔다. 혹시나 카드가 맛이 갈 때를 대비해서
megarec -readsbr 0 orig_sbr.bin
명령을 내려서 원본 SBR을 백업해 둔다. 그 다음 카드를 초기화한 다음 IT 모드용 SBR을 플래시해 주고 다시 한 번 더 초기화한다. 여기까지는 다른 LSI 칩셋 카드와 같다.
megarec -cleanflash 0 (카드에 따라서 여러 번 실행해야 할 수도 있음)
megarec -writesbr 0 SBR-A21.bin (카드가 A21 리비전인 경우)
megarec -writesbr 0 SBR-A11.bin (카드가 A11 리비전인 경우)
megarec -cleanflash 0
그 다음 UEFI 셸로 부팅해서 IT 모드 펌웨어를 밀어넣는다. 저 사이트에 올라온 2118it.p20.bin 파일은 Broadcom 사이트에 올라와 있는 LSI 9211-8i의 20.00.07.00 펌웨어와 동일하다. MD5 체크섬은 동일하나, 찝찝하면 공식 사이트에 있는 파일로 새로 밀어넣어도 상관 없다.
fs0: (UEFI 셸 진입 시 표시되는 USB 메모리 경로로 입력)
sas2hax -o -f 2118it.p20.bin
이 단계에서 카드를 초기화할 수 없다는 오류 메시지가 뜨데, 의도된 결과다. 그래서 시스템을 UEFI 셸로 재부팅한 다음 다시 한 번 더 명령을 수행해 준다.
fs0: (이전 단계에서 실행했던 것과 동일한 경로)
sas2hax -o -f 2118it.p20.bin -b mptsas2.p20.rom
sas2hax -o -sasadd (이전에 기록해 둔 SAS 주소)
마지막으로 DOS로 재부팅한 다음 SBR을 한 번 더 기록해 준다.
megarec -writesbr 0 SBR-A21.bin 또는
megarec -writesbr 0 SBR-A11.bin
IBM M1015 같은 것과는 SBR 및 펌웨어 구조가 달라서 후지쯔용 SBR을 사용하고 sas2flash의 LSI 버전을 사용할 수 없다는 게 차이점이지만, 한 번 플래싱해 두면 HBA 모드로 계속 사용할 수 있다. 후지쯔 카드에 LSI 펌웨어를 올리는 방법 자체가 2016년 5월에서야 최초로 알려졌기 때문에 LSI 펌웨어를 올린 후에 펌웨어 업그레이드는 아직까지는 아무도 시도해 보지 않은 것 같다.
공장 상태의 D2607을 연결하면 MegaRAID Configuration Utility 진입 메뉴가 뜨지만, IT 모드 플래싱이 완료되면 이런 게 뜬다. 이제 이 상태에서는 MegaRAID Storage Manager를 설치해도 HDD 정보만 표시되며, sas2ircu로도 할 수 있는 일은 HBA와 하드디스크 정보 보기밖에 없다. megacli/storcli는 컨트롤러를 인식하지 못한다.
