BluetoothヘッドホンとSurface

Bluetoothヘッドホン自体は以前からありましたが、まだ主力とするには足りてないという印象を持っていました。それが、気が付けば使用環境が整ってきていたので、自分の使用目的に合わせて確かめてみました。

1. aptX

有線ヘッドホンからBluetoothヘッドホンに移行する大前提として、Bluetoothオーディオの高音質コーデックとして最低限の標準であるaptXで接続できるかという問題があります。SBCでは微妙な遅延があるらしいので、とくに動画を見る場合には必須です。

Surface Pro 4

Windows 10が標準でaptXに対応していることは分かっていましたが、実際にSurface Pro 4でどうなるか直接の情報がなく、事前確認は取れませんでしたが、結果から言えばaptXに対応してました。

使用コーデックをプログラム的に判別できないか色々探ってみましたが、手掛かりになる情報は見つからず、最終的にBR1006（後述）をレシーバーモードにして接続した結果、「aptX」で接続と出ました（「aptX low latency」ではなく）。実際、MDR-1000X（後述）と接続して音声と映像をじっと比べても遅延が発生している感じはないので、そういうことなのでしょう。

Nexus 5X

Androidでも明示的にaptXに対応している機種もありますが、Googleブランドの機種はPixelを含めて対応情報がなく、BR1006と接続した結果、予想どおり「SBC」で接続と出ました（Android 7.1.2の状態）。まあ音楽を聴いている限りでは、とくに不満を感じることはないですが。

開発用途との兼ね合いが悩ましいところでしたが、次期バージョン（Android 8.0）の標準でaptX、aptX HD、LDACへの対応が決まったので、もはや問題ではなくなりました。Nexus 5Xはまだアップデート対象ですし。

ということで、PCあるいはスマートフォン側のaptX対応の問題はほぼ終了という状況です。

[追記] Android 8.0

Nexus 5XにAndroid 8.0が配信されたので、早速試したらMDR-1000XがLDACで接続されました。ということで対応完了。

2. Sony MDR-1000X

Bluetoothヘッドホンを見直した切っ掛けはSAOオーディナルスケールの作中で使われていたからで、Sonyのタイアップ企画にはまった感じですが、それは措くとして（ただ、NCヘッドホンをかけたまま料理するのは、台所の危険情報を聞き逃すおそれがあるので止めた方がいいです。自分もやかんが沸騰した音に気づかず、空焚きしかけました）。

で、コラボレーションモデルのMDR-100ABNでいいかと思ったのですが、実機を見にいったら、上位機種のMDR-1000Xは右ハウジングでタッチ操作が可能になっていたので、こちらにしました。

このタッチ操作で、音量調節のほか、曲の前後の頭出しができますが、結構便利です。ハウジングの形に沿って操作ポイントが直感的に分かるので、見えなくても問題はないです。ちなみに、この操作にはWindows 10標準のGrooveミュージックも対応しています。

ヘッドホンの音については、とくに語ることもなく（語るほどの耳を持ってない）。なお、NCヘッドホンとしてはBoseのQuietComfort 25も持っていますが、飛行機の機内でのノイズ抑制はQuietComfortの方が強くかかる感じでした。

3. Inateck BR1006

自分のNCヘッドホンの使用目的の一つは飛行機の機内での使用ですが、機内のヘッドホン端子の音声を無線化しようとすれば、Bluetoothトランスミッターで送信することになります。

Bluetoothトランスミッター/レシーバーの分野は中小の周辺機器ベンターの領域で、aptX対応にはばらつきがありますが、InateckのBR1006は現時点で最新の世代のもので、トランスミッター/レシーバーの両モードでaptX HDまで対応しています。

このBR1006はとてもコンパクトで（重量は単体で16g、附属ケーブルを含めても20gしかない）、ヘッドホンのキャリングケースの隙間に入れておけます。というか、小さすぎて、弾みでケーブルが抜けて座席の間に落ちたりすると回収が大変そうです（実際にそうなりかけた）。せめてケーブルとテープで固定しておいた方がいいかもしれません。

それでいて、使用する分にはとくに問題もなく。内蔵バッテリの持続時間は公称13時間なので、欧州便や北米東海岸便の西回りでも何とか持つぐらいでしょうか。なお、説明書にもありますが、給電中はハム音が混入するので（内部でシールドされてない？）、給電しながら使用するには向きません。

ついでに、BR1006には、使用コーデックをLEDの点滅回数で示す機能があるので、確認用に役に立ちます。

4. まとめ

今更ですが、Bluetoothヘッドホンは予想以上に便利です。今や使用環境も整っているので、これを使わない選択肢はないなと思いました。と言いつつ、コンパクトさではBluetoothイヤホン（ケーブルのないもの）には負けるので、次はそちらかもしれませんが。

WPFのPer-Monitor DPIサポート（その4）

完結編。

• WPFのPer-Monitor DPIサポート（その1）
• WPFのPer-Monitor DPIサポート（その2）
• WPFのPer-Monitor DPIサポート（その3）
• WPFのPer-Monitor DPIサポート（その4）

Windows 10 Creators Updateがリリースされましたが、Windows 8.1から3年経過して、なぜか分かりませんがMicrosoftがようやくデスクトップアプリのPer-Monitor DPI対応に力を入れてきています。今更WinFormsまで対応してくるとは予想外でした。

• High-DPI Scaling Improvements for Desktop Applications in the Windows 10 Creators Update
• Channel 9: High DPI Improvements for Desktop App Developers in the Windows 10 Creators Update

新APIの追加など色々ありますが、WPFの場合は特別なことをしていない限り、関係するのはマニフェストへのPerMonitorV2の追加だけです。
これでWPFでも、例のNon-client areaのスケーリングが自動的にかかるようになります（Creators Update上では。なお、この例はAnniversary Updateより前の対応は自前でやる前提のもの）。

これによって、WPFのPer-Monitor DPI対応はひとまず完成ということで、何か特別なことをしない限りマニフェストに書くだけです。まあUIを作っていると、その何か特別なことが往々にして必要になりますが。

環境光センサーとSurface

現在のタブレットには環境光センサーが付いていて、ディスプレイの明るさを自動調整できるのが普通ですが、実際どういうものかについて。

1. 環境光センサーによる調整

環境光センサー（Ambient Light Sensor）による調整とは、周辺の環境光を感知してディスプレイの明るさを自動調整するものですが、細かくいうと、ディスプレイの設定可能な明るさの範囲内（0～100%で表される。なお、0%は調整可能な下限ということであって、明るさが0ということではない）で、設定された元の明るさからより明るい方に（または暗い方に）寄せて変更します。

この変更幅は明るさの値によって違い、0%と100%では0、すなわち元のままです。その間で、これらの両端から離れるにつれ変更幅は大きくなります。

以下はこれを模式的に示したもので、横軸が元の値、縦軸が調整後の値です。赤線は調整なしの場合で、元の値と調整後の値は同じなので傾き45度の直線になります。対して青線は調整あり（環境光は一定）の場合で、0%から離れるにつれ赤線との差が大きくなっていき、中間を超えて100%に近づくと差が小さくなっていきます。途中で100%に達して、後は水平にそのままということにはなりません。

この調整の計算式はACPI規格で決まっていて、環境光センサーの値、ユーザーが設定した値、ディスプレイに応じてベンダーが用意した値を元に計算が行われます。

• How actual display brightness is determined
• Integrating Ambient Light Sensors with Computers Running Windows 8

この調整後の値を繋いだ線は、環境光が強くなるほど、より上に膨らむ形になります。つまり、0%から出発後に一気に上昇し，ある程度の高さに達すると、後はなだらかに100%に繋がる形になります。

これは結果的に、操作するユーザーの側からすると、値が小さいときは操作量以上に大きく値が変化する一方、一旦大きくなると操作量の割に値が変化しなくなることを意味します。これはユーザーの操作と結果が比例しないということで、UI的には望ましくないです。

2. Windows 10のアクションセンター

Windows 10 Anniversary Updateのアクションセンターでは、ディスプレイの明るさをボタンで変更できるようになっています。

環境光による調整なしの場合は、以下の5段階で、単純に100を4で割った25%刻みになっています。

1. 0%
2. 25%
3. 50%
4. 75%
5. 100%

一方、環境光による調整ありの場合は、数字は出ませんが、実際に設定される値は以下のとおりです（これに環境光による調整が加わる）。

1. 最も暗い: 0%
2. 暗い: 40%
3. おすすめ: 50%
4. 明るい: 60%
5. 最も明るい: 100%

調整なしの場合と違うのは、2.と4.が「おすすめ」の50%から10%の差になっていることです。これは、環境光センサーによって基本的に「いい感じ」に調整されることを前提として、そこからの微調整を想定しているのだと思います。

この方法の問題点は、容易に想像されるように、

• そもそも50%が万人に合う値とは限らない。明るさの感じ方には個人差が大きいし、同じ人間でも状況によって好ましい明るさは違う。
• 環境光による調整がある場合（かつ環境光が十分明るい場合）、上で見たように、50%±10%程度ではさほど変化しないので、調整の役に立たない。

ということです。Microsoftの開発者は環境光センサーに任せておけばいいだろうと、実地に詰めて考えなかったのかなという気がします。ディスプレイの明るさって、個人によって微妙な調整を必要とする、割とデリケートな問題なんですよね。

そのせいか、Creators Updateではアクションセンターに明るさの設定用のスライダーが入るらしいです。それも一つの手っ取り早い解決ではありますが、もう少し工夫する余地はありそうな気がします。

3. Surface Pro 4の場合

さて、Surface Pro 4では実際にどう調整されるかを計測してみたのが以下です。

一見して分かるとおり、50%の部分だけ値を決めて、後は直線で結んだだけです。これには自分も意表を突かれましたが、SurfaceのベンダーとしてのMicrosoftが用意した設定がこうだということです。「おすすめ」の50%で使われる想定なのかもしれませんが、それにしてもざっくりしてます。

一応それぞれの環境を説明すると、

• 437lux: 昼に日差しの入った室内、明るいオフィス内
• 207lux: 夜に照明を点けた住宅内
• 43lux: 薄暗い室内
• 8lux: 暗い室内

といったところです。大体45luxのときに調整がない場合と同じになりそうなので、普通に照明がある環境では常に明るくする方に調整が入ることが分かります。

計測時には、自分のディスプレイの光が環境光センサーになるべく入らないよう遮蔽しましたが、ディスプレイが明るくなるとどうしても2～3lux上がってしまうので、その程度の変動を含んでいます。使用したコードは以下に置きました。

• emoacht/AdaptiveBrightnessChecker

4. UIとして

UIとして見ると、現在の操作方法には問題があります。

• 実際の調整後の値が設定時に分からない。
• 明るさによって操作量に対する調整後の値の変化量が違う。

このため、その時点の環境光下で適当に「いい感じ」に設定して、環境が変わっても自動調整でたまたま「いい感じ」になればそれでよし、ならなければまた設定し直す、の繰り返しという非効率なことになっています。

これを解決するには、最終的にはユーザーの嗜好を学習して調整のデータに加えるAI的なアプローチが必要な気がしますが、差しあたっては調整後の値も表示するようにして見通しをよくするのがいいかもしれません。