• 목록
  • 아래로
  • 위로
  • 쓰기
  • 검색
지식

블루투스 이어폰,헤드폰의 화제거리

싸비 싸비
19935 8 14

 

블루투스 제품을 고르다 보면 다양한 지원코덱들이 존재하고 어떤게 좋은지 고민했던 적이 많으실겁니다.

 

블루투스 코덱은 과연 무엇이며, 어떤 것이 좋은 것일까요?

 

일단 가장 일반적으로 쓰이는 코덱 4가지를 정리해 보겠습니다.

 

1. SBC

블루투스의 오디오 전송 채널인 A2DP의 표준 SBC입니다.

표준이다 보니 모든 블루투스를 송신하는 기기와 블루투스 이어폰,헤드폰이 이 규격을 지원합니다.

과거에는 낮은 압축률로 인하여 192kbps 정도의 압축률을 보여왔으나

요즘에는 16bit /44khz 328kbps 정도는 보내줍니다. 

 

2. Apt-X (https://www.aptx.com/)

과거에 삼성이 인수한적도 있으나 지금은 퀄컴이 소유하고 있는 apt-x입니다.

안드로이드 폰들은 대부분 송신을 지원하지만 애플 제품들은 지원하지 않습니다.

종류는 1. apt-x 2. apt-x hd 3. apt-x low latency 세가지 종류로 나누어져 있는데

hd의 경우 24bit/ 44khz 를 지원하며 low latency는 전송속도를 빠르게해 딜레이를 줄인 코덱이라네요.

 

3. AAC

자주 보시던 그 AAC 코덱이 맞습니다. ㅎ 

애플에서만 독자적 블루투스 코덱으로 쓰이고 있습니다.

좀 한계가 많은 편인데 aac 블루투스 송신을 사용해야하고 음악파일도 이 코덱으로 되어있어야합니다.

주로 닥터드레 beets 나 보스에서 지원하는 경우가 자주 보입니다.

 

4. Ldac

소니에서 자체적으로 쓰이고 있는 코텍입니다.

아직까진 소니기기에서만 지원하고 있으나 추후에 안드로이드 스마트폰에도 지원한다네요.

가장 높은 24bit/96khz 샘플링을 지원하지만... apt-x hd 비해 좋다고 말하....는 건 힘들거 같..

소니가 밀고 있는 hi-res 를 구현해준다는 점에서 의미가 있겠네요. 

(자세한 건 http://www.stylezineblog.com/3458)

 

 

 

코덱을 보면서 생각해보셔야 할게 있습니다.

코덱들의 경우  일반적으로 압축률이 높으면 ,

다시 디코딩하는데 시간이 더 많이 걸리고

처리해야 할 일도 많아지니 배터리 용량을 더 잡아먹을 가능성이 높습니다.

 

apt-x의 경우 sbc보다 압축률이 높지만 전송처리 속도나 배터리 소모량도 적게 소비한다고 발표했으나

Ldac의 경우 apt-x 나 sbc에 비해 음질은 뛰어날 수 있으나 속도나 배터리 소모량에서는 어떤지는.....

(찾아보려 했으나 정보가 안 나와서.. 자세하게 아시는분은 따로 피드백 주시면 감사하겠습니다. )

 

 

제 생각에는 코덱에서 어느정도의 샘플링을 지원한다는게 중요하기 보다는

블루투스 신호 전달 사이에 생기는 화이트노이즈를 줄이는게 더 중요하다고 생각합니다.

 

 

과거에는 화이트 노이즈가 매우 커서 블루투스 이어폰,헤드폰을 쓰기 힘들었으나

요즘에 나오는 블루투스 제품들은 대부분 설계가 잘 되어 있어서 엄청 조용한 곳이 아니면 느끼기 힘들더군요.

 

하지만 아직도 사람 귀에 들릴만한 노이즈가 발생되므로, 샘플링 보다는 실질적인 노이즈 제거를 위한

설계가 필요하다고 생각합니다. 

 

 

이제 본격적으로 제가 가장 문제 있다고 생각하는 "블루투스 지연" 문제를 다뤄보겠습니다.

 

블루투스는 무선으로 보내는 만큼 선보다는 느리다는 건 알려진 사실이지요.

블루투스 지연이 생기면 영상이나 게임을 할때 화면과 소리가 싱크가 맞지 않는 문제가 생깁니다.

음악의 경우는 별 문제는 아니지요. 

 

블루투스가 지연이 생기는 이유는 크게 2가지로 정리 할 수 있습니다.

1) 코덱이 무선으로 전송되는 속도

2) 코덱을 변환해서 오디오 신호로 바뀌는데 걸리는 속도

 

1) 코덱이 무선으로 전송되는 속도는 과거 블루투스 버젼이 낮았을때는

전송 속도가 느려서 50ms(밀리세컨드) 이상 발생하는 경우도 있었으나

최근에는 apt-x는 전송속도가 최소 1.9ms만에 전송한다고 하며, sbc를 비롯한 다른 코덱에서도

큰 지연은 발생하지는 않는 것 같습니다. 

 

2) 가장 큰 문제는 코덱을 변환해서 소리를 돌려주는데 지연이 발생합니다.

프레젠테이션1.png블루투스 전송 과정을 간단히 표현한 도식도입니다.

블루투스 채널 A2DP는 패킷전송 구조를 통해 신호를 전달합니다.

스테레오 음원은 L,R로 나누어져 있기 때문에 따로 신호처리를 해줘야하는 문제가 발생합니다.

따라서 위 방법과 같이 두가지 방법으로 나누어지게 됩니다.

 

1) 첫번째 그림에서 보듯이 한 패킷에서 한번에 처리 후 L,R로 보내는 방법이 있습니다.

이 방법은 지연이 거의 발생하지 않는 대신에

디코더 안에서 서로의 신호 간섭이 일어나 신호의 정확도가 떨어지는 문제가 있습니다.

 

2) 두번째 그림에서 보듯이 두 패킷으로 나누어 처리 후 L,R로 보내는 방법이 있습니다.

이 방법은 신호 간섭은 비교적 덜 일어나는데 처리 과정에서

서로 패킷간의 처리 속도와 내보내는 속도를 맞춰야 하므로 지연이 발생합니다.

 

대부분의 블루투스 제품이 두번째 방식을 채택하는 것으로 보여집니다.

 

그렇다면 이 문제가 실질적으로 제품에서 어떻게 나타나는지 보여 드리겠습니다.

 

캡처.PNG

 

3.PNG

 

 

영디비에서 측정한 블루투스 제품마다 딜레이 정도를 표로 정리해봤습니다.

 

영디비에서 측정장비로 사용하는 Audio Precision 블루투스 모듈은 sbc와 apt-x 밖에 지원하지 않으므로

두 가지 코덱만 비교해 보겠습니다.

 

표를 간단히 분석해 보자면 제가 말했듯이 코덱의 종류에 따라서 지연속도가 크게 차이나지 않습니다.

(apt-X 평균:132.5ms , SBC 평균:141.4ms *백비트 고3,파워비츠, 이어린, 아이콘 X제외)

apt-X 의 경우 전달 속도를 1.9ms 라 해놓고 저렇게 크게 나타나는 이유는

말 그대로 위에 있는 두번째 처리 과정에서의 지연이 크게 작용하는 것 같습니다.

 

속도로는 백비트 go 3가 매우 빠른데 커스텀 코덱을 사용한 점도 있고 

설계를 매우 잘한 결과로 보여집니다.

 

반면에 파워비츠2 , 이어린, 아이콘 x는 지연속도가 심각하게 긴데

 

파워비츠는 나온지 좀 된 이어폰으로 구세대 코덱을 쓰거나

기술의 발전으로 인해 좀 떨어지는 결과치를 보입니다.

 

비교적 최근에 나온 이어린이나 icon X의 경우 아예 선이 없는 

TMS (True Wireless stereo) 제품의 문제점중 하나 입니다.

블루투스의 경우 2400mhz  신호 대역폭을 사용하는데 이 대역폭이 사람의 신체를 잘 통과하지 못하는데

귓속에 들어가는 경우 이로 인해 더 큰 지연이 발생하게 됩니다.

 

에어팟의 경우 이런 문제가 적은데,

처음 나왔을때 많은 조롱거리가 되었던 귀 밖에 나왔던 안테나가 

블루투스 신호를 전송 받아 이 문제가 덜한 것 같습니다.

 

 

그렇다면 어느정도의 딜레이가 사람들이 시각적 데이터에 비해서 소리가 지연된다고 느낄까요?

 

https://tech.ebu.ch/docs/r/r037.pdf

EBU (유럽 방송 연합) 에서 제공하는 권고안에 따르면

화면에서 발생하는 소리는 일반적으로 해당되는 화면보다

최대 4ms 먼저 나오거나 15ms 정도 뒤에 나온다고 합니다.

 

지연을 발생시킨 이후에 50% 이상의 사람이 이상하다고 느낀 경우를 시간초로 나타낸 결과.

소리가 먼저 나오는 경우 40ms 이상의 지연이 생기면 이상하다고 느꼈고

나중에 나오는 경우 60ms 이상의 지연이 생기면 이상함을 느꼈다고 합니다. (ㅎㄷㄷ)

 

가장 넉넉한 60ms 라고 생각해도 이를 만족하는 제품은 백비츠 go3 밖에 없네요....

 

결론

 

블루투스의 현 상황에서 가장 문제시 되는 건 코덱에 따른 음질보다는 지연문제를 해결하는데 있다고 봅니다.

하지만 그 어떤 제품도 스펙시트에 지연속도를 표시하지는 않습니다.

지연속도를 확인하기 위해서는 영디비와 같은 소비자 평가사이트에서 보는 방법뿐... 

 

이 문제가 조속히 해결되거나 알려져야 한다는 점을 강조하며 이만 글을 마칩니다.

신고공유스크랩
박지훈 박지훈님 포함 8명이 추천

댓글 14

댓글 쓰기
profile image
좋은글 잘 봤습니다. 저같은 막귀에게음질은 apt-x 정도만되도 괜찮다고 생각합니다.

저도 음질보다는 신호지연이 문제아닌가 했는데 콕 찝어주셨네요. 그런데 60ms이상이면 이상함을 느낀다니... 생각보다 민감하네요
15:54
17.03.28.
profile image
싸비 작성자
KIMBBAM
네 저도 엄청 생각보다 예민해서 놀랐네요..
영디비에서 측정치를 공개 안 했으면 저도 모를뻔...
16:26
17.03.28.
profile image
대박!!! 이렇게 상세하게 정리를 하다니요!!!!
딜레이 타임을 이렇게 그래프로 쭈~욱 보니 새롭네요. ㅋ

몇가지 질문이 있어요.
1. AAC 코덱은 음악파일도 AAC로 되어 있어야지 AAC로 동작한다는 건가요?
2. 두번째 그림을 볼때 인코딩과정에서 한패킷으로 묶는 것같이 표현을 하셨는데, 이 부분은 그림이 표현이 잘못된게 아닌가 합니다.
18:33
17.03.28.
profile image
싸비 작성자
영디비
1. 넹 음악파일도 aac여야 합니다.
2. 제가 문돌이라.. 사실 회로도는 잘 몰라서.. 인코딩 과정에서 패킷도 2개로 동작하나요?
18:59
17.03.28.
profile image
싸비
음... 문맥상으로 이해가 잘 안되는게 있어요. 저도 확실하게 알고있는게 아니라서요.
첫번째는 한 패킷에서 한번에 처리 후 L,R로 보내는 방법
두번째는 두 패킷으로 나누어 처리 후 L,R로 보내는 방법
제가 이해를 하기로는 인코딩에서 한 패킷 혹은 두 패킷으로 처리를 해서 무선으로 신호를 보내고 디코딩 과정해서 한 패킷으로 들어온 신호는 나누는 작업을 하고, 두 패킷으로 들어온 신호는 바로 L/R로 보는 것으로 이해를 했습니다.

어디서 보셨는지 출처를 주시면 이해하기가 훨씬 쉬워질 것 같네요~ ^^
20:37
17.03.28.
profile image
싸비 작성자
영디비
사실 인코딩은 잘 모르겠고
디코딩 과정에서 집중해서 만든 건데요.
인코딩 쪽에서 나오는 아웃풋은 어차피 블루투스 채널 A2DP하나 아닌가요?
해석할때는 패킷을 두개로 하나 한개로 하냐의 문제를 다룬 것입니다.

아까 급하게 글을 쓰느라 링크를 못걸었는데
http://www.aes.org/e-lib/browse.cfm?elib=18236
요 논문 참고해서 글을 썻습니다.
21:36
17.03.28.
profile image
파워비츠2뿐만 아니라 파워비츠3도 지연속도 엄청 깁니다 ㅎㅎ 옛날거라기보단 비츠가 블투 이어폰 만드는데에 지연속도 길게 만드는것 같네요. 헤드폰은 안그런데 말이죠. 새로나온 beatsx는 어떤진 잘 모르겠습니다만.
23:42
17.03.28.
profile image
싸비 작성자
PAPER
흠... 제가 비츠 x를 쓰는데 고건 지연시간이 짧더군요. W1칩이라 그런가...
07:23
17.03.29.
profile image
싸비
파워비츠3도 W1칩을 사용했는데말이죠 ㅠㅠ
07:51
17.03.29.
profile image
싸비 작성자
PAPER
생각해보니 그것도 그렇네요... 왜 그럴까요? 측정을 새봐야돠나...
08:33
17.03.29.
profile image
싸비
제가 생각하기엔 파워비츠 시리즈가 구조상 지연속도가 길수밖에 없도록 설계된것 같습니다만...
18:34
17.03.29.
profile image
PAPER
파워비츠는 하우징부가 크기 때문에 구조상 오히려 좋을 텐데요.
21:43
17.03.29.
profile image
영디비
그런가요? ㅎㅎ 정말 미스테리네요...
22:48
17.03.29.
profile image
저도 예전에 블투 헤드폰으로 게임을 하고자 동글까지 샀지만 결국 다시 스피커로 회귀했는데 가장 큰 이유가 딜레이때문이었습니다. 이제 무선마우스와 무선키보드는 어느정도 게이밍에도 무리가 없을 만큼 발전한 것 같은데, 헤드폰은 아직 영상과 맞물리기에는 가야할 길이 머네요.
16:06
17.04.11.
권한이 없습니다. 로그인
에디터 모드

신고

"님의 댓글"

이 댓글을 신고하시겠습니까?

댓글 삭제

"님의 댓글"

이 댓글을 삭제하시겠습니까?

공유

퍼머링크