kariaの日記 @ Alice::Diary

ノリツッコミの鳩子がはてなブログ書いちゃうよ

Bluetoothで気になる「音ズレ」を対処するため調べたこと全部書く

Bluetoothイヤホン(ヘッドホン)を使用していると音声の遅延、ラグが発生する。

音楽を聴いているだけとか、VTuberの雑談配信を見ている程度なら多少遅延していても気にならないのだが、アニメや実写動画を見始めると途端に遅延が気になってしまう。動画の動き・口パクと音声のタイミングがズレてしまうからだ。

このズレをどうにかするための方法を探ったのでメモしておく。

人間はどのぐらい音ズレが許容できるのか

そもそもの話として、人間は対面で会話するときでも音と光の速度の違いによる知覚のズレがあり、このズレは対面する距離が離れていけばいくほど拡大していく。そのため人間の感覚として多少の口パク(リップシンク)のズレは許容できるようだ。では「多少」とは数値にすると一体いくつなのか。

テレビ会議教科書」というサイトに以下の記述が確認できた。

vcbook.vtv.co.jp

NHKのデータが基になって,勧告ITU-R BT.1359が作られました[5-33].そこでは許容限/検知限は音声が遅れる場合は185/125 ms,進む場合は90/45 msと図示されていて,番組が視聴者に届いたとき許容限を越える誤差があってはならないと規定しています.

この記述通りだと185msまでは許容範囲に入るが、実際の放送の基準ではもっと厳しく既定されているとのこと。また、アナウンサーのしゃべりよりも楽器の音のほうが許容範囲が小さいらしい。なるほどね。

実際どのぐらいズレてるのか確認したい

それでは、音ズレの有無をわかりやすく確認する方法を覚えておこう。メトロノームの動画を見るとよいというTwitterの発言を見かけたのでYouTubeで見てみた。

youtu.be

この動画を一旦有線で視聴して音が出るタイミングを覚えておき、その後Bluetoothに切り替えてもう一度見てみる音ズレが発生していることが感覚的に理解できると思う。なお、後述する要素に関わってくるのだが、この動画によるチェックはスマホではなくWindowsで行うことをオススメする。

さて、動画での確認する手法はあくまで人間の感覚に頼ることになり正確さはない。多少音ズレが発生していても動画の内容や音ズレの程度によっては「あまりズレているように感じないな?」と思うケースもある。Google検索では「このコーデックは●●●msecの遅延があり~」と根拠不明の数字を出しているサイトが見つかるのだが、そのサイトによって言う事が異なっており信憑性に欠ける。

より正確な比較方法を求めてさまよっていたところ、価格コムにある「Bluetoothイヤホンのオーディオレイテンシ その3」というスレッドに、Audio Latency Test Appというアプリを使って具体的なレイテンシを様々なイヤホンの実機で計測している方がいた。

bbs.kakaku.com

この方がまとめているスプレッドシートが非常に便利である。

docs.google.com

何をどうがんばったって遅延が大きいイヤホンというのはあるし、平均的に遅延が大きいコーデックというのもある。それを単一の人が単一の測定方法で計測しているというのが非常にありがたい。

コーデック毎のおおよその傾向を見てみると、特に、音質が良くて最近採用例の多いLDACは遅延が大きいようだ。私が普段使用しているSony WF-1000XM4ではAAC接続で308ms、LDAC接続で269msの遅延があるという測定結果であった。どちらのコーデックにしても、先程の185msというボーダーラインを越えて遅延していることがわかる。

具体的な対処法

いよいよ対処法について述べていく。簡単に言うと「ハードウェア的対処」「ソフトウェア的対処」の2種類がある。どちらも一長一短なので、予算や環境に応じて検討することになるだろう。

ハードウェア的対処:遅延の少ないコーデックを利用する

こちらは「遅延が少ないコーデックを常時使おう」という戦略。送受信するハードウェアの組み合わせが重要であり、つまりカネで物を言わす作戦である。

今から遅延が少ないコーデックを選択するならApt-x Adaptive一択だ。Apt-X LLも低遅延なコーデックなのだが、スマートフォンに搭載できないというデメリットが痛すぎるため、後継のApt-X Adaptiveを選ぶほかない。

Apt-X Adaptiveは、状況に応じて低遅延モードと高音質モードを自動的に選択してくれるらしい。低遅延モードのほうなら期待ができそうだ。ということで実際に購入したハードウェアの組み合わせを以下に示す。

送信側 Creative BT-W4

「BT-W4はApt-X Adaptiveの低遅延モードを常時使用してくれる」という書き込みを信用して購入した。したのだが、購入した直後にBT-W5がリリースされ、低遅延モードと高音質モードの切替をWindows上のソフトウエアで明示的にできるようになった。完全に求めていた用途であり、今から買うなら絶対BT-W5だ。

なお参考までに、AndroidスマートフォンのPixel7もApt-X Adaptiveに対応しているが、低遅延モードなのか高音質モードなのかは選択することができない。また、AliExpressなどで安価なBTトランスミッターが見つかるが、ガチャがしたいのでなければ避けるのが無難だ。

受信側 SOUNDPEATS Mini Pro

Apt-x Adaptiveに対応したイヤホンで程よい値段であり、かつ先程のスプレッドシートでApt-x Adaptive接続時の遅延が104msと小さいものを選んだ。実際、BT-W4との組み合わせで動画を見ていても口パクのズレが気になることはまずない。

気をつけたいのは、同メーカーの Mini Pro HS はLDAC対応(Apt-X Adaptive非対応)ということだ。他メーカーのものでも、似通ったモデル名とかバージョン番号の違いで対応コーデックが異なることがあるのでよく調べてから購入するようにしたい。

なお、この対処法が取れるのであれば、ロジクールなどが発売している遅延の少ない独自無線方式のワイヤレスヘッドホンを使うという手もある。Bluetoothヤメロ。

ソフトウェア的対処:音声が遅延している分だけ映像を遅らせる

こちらは既にオーディオデバイスは買ってしまっており、追加投資なしにソフトウェア的に対処したい場合の対処法である。

DelayReportingとは

いきなりだが、前提知識としてBluetoothプロトコルの話をする。

AVDTPとは Audio/Video Distribution Transport Protocol の略で、オーディオコーデックよりも下のレイヤーに位置するプロトコルである。以下のブログに、パケット内にAVDTPのヘッダーとコーデック(SBC)のフレームが収められている図解が書かれていてわかりやすかった。

cornestech.co.jp

そのAVDTPのバージョン1.3の仕様書が以下のサイトにある。サイトは日本語だがPDFは英語だ。

www.bluetooth.com

前置きが長くなったが、8.21.9に記載されている「Delay Reporting」という仕様が重要なキーとなる。

Delay reporting enables synchronized playback of audio and video by providing delay reports from a SEP.

SEP(Stream End Point)つまりイヤホン側から遅延情報を提供することで、音声と映像の同期を取れるようにするよ、ということらしい。なるほど、音声が遅れるならその分映像も遅らせればよいのだ、という発想だ。

これだけ聞くと良いことずくめのように見えるが、気になる記事も見つかった。

answers.microsoft.com

AVDTP1.3に対応しているとしても、アプリケーションがDelay Reportingを使って映像を遅らせてくれないと意味がないらしい。そりゃそうだ。

実際に試してみた

実際のところ、たしかにコーデックがAAC or LDACであっても音ズレが感じられないアプリケーションが確かに存在する。

  • Android + YouTubeアプリ・PrimeVideoアプリ(LDACコーデック)
  • iOS + YouTubeアプリ・PrimeVideoアプリ(AACコーデック)

これらの組み合わせでは、遅延が大きいはずのWF-1000XM4を使用しても音ズレは感じられなかったので、Delay Reportingに対応しているのだろう。少なくともiOSAppleアクセサリーのデザインガイドラインで対応していると明言している

しかしながらOSがWindowsの場合は条件が厳しくなる。明確に音ズレがないと言えるのは、以下の条件を両方満たした場合のみであった。

  1. アプリケーションはWindows標準のメディアプレーヤーを利用する
  2. Windowsサウンド設定でBluetoothバイスを直接指定する(仮想オーディオドライバを挟まない)

上記の条件を満たさない状況下、たとえば以下のアプリ使用したときはズレを感じることがあった。

VoiceMeeterという仮想オーディオミキサ(オーディオドライバ)を使用した場合も、やはりズレが発生するように感じた。挙動からの推測だが、仮想ドライバが中間に挟まっていることにより、Delay Reportingをメディアプレーヤー側が受け取れなくなるものと思われる。

なお、VLC Media Playerの場合は設定の中に「オーディオ非同期調整」という項目があり、人力Delay Reportingを行える。WF-1000XM4の場合、-250ミリ秒あたりに設定するとズレが気にならなくなった。常にBluetoothを使い続けるならこの設定を入れっぱなしにするという手もありそうだ。

ここまできちんと読んだ方ならわかると思うが、Windows + Chrome (YouTube) という私が最も長時間視聴する組み合わせでは、ドライバがなんであれDelayReportingは機能しないし、調整する方法も現状見つかっていない。もし何らかの対処法を知っている方がいたら教えていただきたいと思う。