반응형

테스트 기종: 갤럭시 노트8 (SM-N950N)
Android OS: 오레오 (Oreo, 8.0.0)
테스트 스피커: MI Bluetooth Speaker


언젠가부터 스마트폰에서 블루투스 장비와 연결하면 볼륨이 내가 생각하는 것과 다르게 너무 극단적으로 출력되기 시작했다. 예를 들면, 스마트폰에서 볼륨을 제일 작은 단계로 딱 한 칸만 올렸는데, 실제로 출력되는 소리는 가장 작은 단계가 무색하게 아주 크게 출력되었다. 개인적으로는 샤오미의 블루투스 스피커 또는 현대자동차의 순정 네비와 블루투스로 연결할 때 이런 현상이 나타났다.

특히 샤오미 블루투스 스피커의 경우에는 전원버튼 외에는 독립된 볼륨 조절 버튼이 없다. MI Bluetooth Speaker를 연결한 뒤에 음악을 켜고 스마트폰에서 단지 볼륨을 딱 한 칸만 (제일 낮은 단계) 올렸을 뿐인데, 거의 최대 출력과 다름없는 크기로 소리가 갑자기 쩌렁쩌렁 울려 퍼져서 매우 당황했다.


확인해 보니 이건 블루투스 장비와의 볼륨 동기화 설정 때문에 나타나는 문제로 확인되었다.
비단 안드로이드뿐만 아니라 윈도우 운영체제에서도 설정에 따라 똑같은 현상이 일어날 수 있다.

안드로이드 운영체제 기반인 삼성 갤럭시 노트8에서는 아래와 같이 설정을 해제할 수 있다.


1. 설정 > 연결 > 블루투스에 들어가서, 오른쪽 상단의 메뉴 (점 세개)를 누른다.
메뉴 중에서 "미디어 음량 동기화"를 선택한다.


2. 미디어 음량 동기화 설정 화면에서 토글 버튼을 눌러서 "사용 안 함"으로 설정한다.


이렇게 미디어 음량 동기화를 해제한 뒤에 스마트폰의 볼륨 버튼을 사용하여 미디어 음량을 조절하면 작은 음량부터 설정할 수 있다.

반대로 스마트폰에서 미디어 음량을 충분히 키웠는데도 블루투스 장비에서 들리는 소리가 너무 작아서 문제가 될 때에는 위의 방법대로 설정에 들어가서 미디어 음량 동기화를 다시 켜면 된다.


참고로 삼성 갤럭시 스마트폰에서 볼륨 버튼 한 번으로 조절할 수 있는 볼륨의 크기를 더 미세하게 조정하고 싶으면 별도의 앱을 설치해야 한다. 구글 플레이 스토어 또는 갤럭시 앱스에서 "Sound Assistant" 앱을 설치하면 된다. 앱을 설치한 뒤에 고급 설정에서 음량 간격을 10보다 작게 할 수 있다.




반응형
블로그 이미지

Bryan_

,
반응형

테스트 대상 기기: 삼성 갤럭시 노트3 네오, LGU+ (SM-N750L)

Android 버전: 4.4.2


스마트폰을 통한 네트워크 실험을 하는 과정에서, 여러 차례 와이파이에 연결된 스마트폰에 ping을 날려야 하는 경우가 있었다. 화면이 꺼져 있더라도 옵션을 통해서 와이파이에 항상 연결되어 있게 할 수는 있는데, 유독 화면이 꺼져 있을 때에 ping 속도가 느린 것 같다는 느낌이 들어서 실제로 테스트를 해 보았다.

샘플 수가 20개라서 사실 많지는 않지만, 그래도 동일한 환경에서 주변에 다른 방해하는 기기가 거의 없는 새벽 시간대에 해 본 것이라서 어느 정도 의미는 있을 것으로 생각한다.


테스트 환경으로, 라즈베리파이 2B에 hostapd를 돌려서 가상 AP로 만들고, 스마트폰이 그 AP에 연결되도록 했다.

라즈베리파이는 Raspbian Jessie 운영체제에 Atheros ath9k-htc 기반의 USB 무선랜카드를 달고 있고, IEEE 802.11n 모드로 AP를 돌렸다.

테스트용 스마트폰 외에 무선으로 연결된 다른 연결된 기기는 없었다.


아래는 화면이 꺼져 있을 때, 의 ping 결과이다.

pi@raspberrypi ~/exp $ ping 10.0.5.10

PING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.

64 bytes from 10.0.5.10: icmp_seq=1 ttl=64 time=289 ms

64 bytes from 10.0.5.10: icmp_seq=2 ttl=64 time=113 ms

64 bytes from 10.0.5.10: icmp_seq=3 ttl=64 time=344 ms

64 bytes from 10.0.5.10: icmp_seq=4 ttl=64 time=157 ms

64 bytes from 10.0.5.10: icmp_seq=5 ttl=64 time=204 ms

64 bytes from 10.0.5.10: icmp_seq=6 ttl=64 time=164 ms

64 bytes from 10.0.5.10: icmp_seq=7 ttl=64 time=188 ms

64 bytes from 10.0.5.10: icmp_seq=8 ttl=64 time=9.65 ms

64 bytes from 10.0.5.10: icmp_seq=9 ttl=64 time=237 ms

64 bytes from 10.0.5.10: icmp_seq=10 ttl=64 time=276 ms

64 bytes from 10.0.5.10: icmp_seq=11 ttl=64 time=80.7 ms

64 bytes from 10.0.5.10: icmp_seq=12 ttl=64 time=105 ms

64 bytes from 10.0.5.10: icmp_seq=13 ttl=64 time=126 ms

64 bytes from 10.0.5.10: icmp_seq=14 ttl=64 time=205 ms

64 bytes from 10.0.5.10: icmp_seq=15 ttl=64 time=220 ms

64 bytes from 10.0.5.10: icmp_seq=16 ttl=64 time=258 ms

64 bytes from 10.0.5.10: icmp_seq=17 ttl=64 time=254 ms

64 bytes from 10.0.5.10: icmp_seq=18 ttl=64 time=290 ms

64 bytes from 10.0.5.10: icmp_seq=19 ttl=64 time=312 ms

64 bytes from 10.0.5.10: icmp_seq=20 ttl=64 time=135 ms

^C

--- 10.0.5.10 ping statistics ---

20 packets transmitted, 20 received, 0% packet loss, time 19025ms

rtt min/avg/max/mdev = 9.658/198.845/344.289/84.791 ms



아래는 스마트폰 화면을 켜고, 바탕화면을 전환하거나 카카오톡 앱을 한번 켜 보는 등 화면을 켜져 있도록 유지했을 때의 ping 결과이다. 카카오톡을 켤 때 잠시 서버에 접속하는 경우를 제외하고는 스마트폰에서 별도로 트래픽을 발생시키지 않았다.


pi@raspberrypi ~/exp $ ping 10.0.5.10

PING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.

64 bytes from 10.0.5.10: icmp_seq=1 ttl=64 time=146 ms

64 bytes from 10.0.5.10: icmp_seq=2 ttl=64 time=67.5 ms

64 bytes from 10.0.5.10: icmp_seq=3 ttl=64 time=81.2 ms

64 bytes from 10.0.5.10: icmp_seq=4 ttl=64 time=133 ms

64 bytes from 10.0.5.10: icmp_seq=5 ttl=64 time=128 ms

64 bytes from 10.0.5.10: icmp_seq=6 ttl=64 time=147 ms

64 bytes from 10.0.5.10: icmp_seq=7 ttl=64 time=175 ms

64 bytes from 10.0.5.10: icmp_seq=8 ttl=64 time=98.5 ms

64 bytes from 10.0.5.10: icmp_seq=9 ttl=64 time=109 ms

64 bytes from 10.0.5.10: icmp_seq=10 ttl=64 time=9.62 ms

64 bytes from 10.0.5.10: icmp_seq=11 ttl=64 time=66.1 ms

64 bytes from 10.0.5.10: icmp_seq=12 ttl=64 time=81.9 ms

64 bytes from 10.0.5.10: icmp_seq=13 ttl=64 time=108 ms

64 bytes from 10.0.5.10: icmp_seq=14 ttl=64 time=139 ms

64 bytes from 10.0.5.10: icmp_seq=15 ttl=64 time=146 ms

64 bytes from 10.0.5.10: icmp_seq=16 ttl=64 time=75.2 ms

64 bytes from 10.0.5.10: icmp_seq=17 ttl=64 time=5.52 ms

64 bytes from 10.0.5.10: icmp_seq=18 ttl=64 time=4.06 ms

64 bytes from 10.0.5.10: icmp_seq=19 ttl=64 time=4.30 ms

64 bytes from 10.0.5.10: icmp_seq=20 ttl=64 time=188 ms

64 bytes from 10.0.5.10: icmp_seq=21 ttl=64 time=78.3 ms

^C

--- 10.0.5.10 ping statistics ---

21 packets transmitted, 21 received, 0% packet loss, time 20028ms

rtt min/avg/max/mdev = 4.062/95.085/188.859/54.672 ms



최소값, 최대값, 평균 모두 차이가 남을 알 수 있다.

평균을 기준으로 대략 2배 가량 전송시간(round trip time)의 차이가 발생했다.

참고로 같은 증상이 삼성 갤럭시 넥서스(버전 4.1.1)에서도 나타났다.


무슨 연유로 어디에서 이러한 지연이 발생하는지는 정확하게 알 수 없다. 하지만 아마도 스마트폰에서 의도적으로 지연을 발생시켰을 것으로 예상되며, 그 이유는 여러가지가 있겠지만 에너지 절약 차원의 목표가 있을 것이라고 추측만 하고 있다.

네트워크 실험을 할 때에는 (물론 화면을 끄고서 실험할 일은 거의 없겠지만) 스마트폰 화면의 꺼짐 유무도 잘 확인하는 것이 좋겠다.



반응형
블로그 이미지

Bryan_

,