エンドツーエンド遅延はどの区間で構成されるか
Bluetoothイヤホンの遅延対策の第一歩は、遅延を分解して捉えることです。ユーザーが感じる音と映像のずれは単一の数値ではなく、四つの区間の合計です。
- 送信側のバッファ：動画アプリは通常100-300ms、ゲームエンジンは20-40msまで圧縮できる
- 符号化とパケット化：エンコーダは1フレーム分のデータを蓄積する必要があり、SBCの代表的なフレーム長は4-8msに相当する
- 無線伝送と再送：Bluetoothのスロットは通常625マイクロ秒、再送のたびに約10-20msが加算される
- 受信側のバッファと復号：ジッタバッファは40-200msが代表値で、最大の制御可能変数である
| 区間 | 代表的な範囲 | 制御可能性 |
|---|---|---|
| 送信側バッファ | 20-300ms | アプリケーションが決定 |
| 符号化・パケット化 | 4-15ms | エンコーダが決定 |
| 無線伝送と再送 | 5-30ms | 環境の干渉に依存 |
| 受信バッファと復号 | 40-200ms | ファームウェアの戦略が決定 |
SBC、AAC、aptXファミリー、LDACの比較
LDACとaptXの違いの核心は設計目標の差にあります。
SBCはA2DPの必須コーデックで、ビットレートは通常192-328kbps、実測のエンドツーエンド遅延は約150-250msで、互換性の基準線となります。AACはiOSエコシステムの事実上の標準で、ビットレートは通常128-256kbps、アップル機器での実装品質は高いものの、Android側はエンコーダの品質にばらつきがありバッファも大きいため、遅延も150-250msになります。
aptXファミリーは遅延がより低くなります。クラシックaptXは352kbpsでエンドツーエンド約100-150ms、aptX Low Latencyは30-40msを実現しますが送信側も対応している必要があります。aptX Adaptiveは279-420kbpsを動的に切り替え、公称遅延は50-80msです。
LDACは帯域を重視し、330、660、990kbpsの3段階に対応し最高96kHz/24bitですが、無線の負荷が大きく、干渉環境では自動的に段階を落とすため遅延は通常150msを超えます。
| コーデック | ビットレート | 最高仕様 | エンドツーエンド遅延 | 送信側への依存 |
|---|---|---|---|---|
| SBC | 192-328kbps | 48kHz/16bit | 150-250ms | なし |
| AAC | 128-256kbps | 44.1kHz/16bit | 150-250ms | なし |
| aptX | 352kbps | 48kHz/16bit | 100-150ms | あり |
| aptX Adaptive | 279-420kbps | 48kHz/24bit | 50-80ms | あり |
| LDAC | 330-990kbps | 96kHz/24bit | 150-250ms | あり |
LE AudioとLC3がもたらすもの
LE AudioのLC3はBluetooth音声の土台の切り替えですが、単に遅延の低いコーデックという話ではありません。
LC3の設計目標は、同一ビットレートでSBCより良い音質を提供するか、同一音質でビットレートをSBCの半分に下げることです。代表的な動作域は160-320kbpsで、160kbpsでの主観音質はすでにSBC 328kbpsに近づきます。
遅延面では、LC3のフレーム長は10ms（7.5msも選択可能）で、アイソクロナスチャネルと組み合わせることで理論上エンドツーエンド20-30msが可能です。アイソクロナスチャネルはブロードキャストオーディオも導入し、一つの送信機から無制限の受信機へ配信できます。
LE Audioの工学的な価値は三つあります。同一音質で無線の動作時間が短くなりTWSの連続駆動に実質的な利得があること、アイソクロナスチャネルのタイミングが従来の非同期リンクより制御しやすく遅延の上限が確定しやすいこと、そしてブロードキャストオーディオによる共有音声や補聴といった新しい形態が生まれることです。
ただし実装には前提があります。送信側と受信側の両方が対応している必要があり、現時点ではスマートフォンとOSの対応が段階的に進んでいる段階です。そのため今後数年間は、クラシックオーディオとLE AudioのデュアルモードがTWSの安全な構成であり続けます。代償としてプロトコルスタックと認証のコストが上昇します。
ゲーム、配信、カラオケの低遅延方式
用途ごとの遅延要件は概ね次の通りです。
- 動画視聴：100ms未満、超えると口の動きと音がずれる
- 対戦型モバイルゲーム：60ms未満、超えると銃声と画面が乖離する
- リズムゲーム：40ms未満、超えると判定がずれる
- 楽器練習：20ms未満、超えると演奏に支障が出る
より抜本的な方式はA2DPを迂回し、USBレシーバと組み合わせた独自の2.4GHzプロトコルを使うもので、エンドツーエンド20-40msを実現しBluetoothスタックの制約を受けません。欠点はレシーバが別途必要になることです。
配信とカラオケには追加の制約があります。上りのマイク音声と下りの伴奏を同時に扱う必要があるためです。Bluetooth HFPの上りはモノラル狭帯域で、mSBCでも16kHzにとどまり歌唱には不十分です。この種の製品では通常、上りを独自リンクまたはUSB、下りをBluetoothという構成をとります。
音画同期と遅延補正
音画同期は遅延をゼロにするのではなく、補正によって成立します。
動画視聴では、プレーヤーがシステムから報告される音声遅延を読み取り、映像フレームの再生を遅らせて一致させます。AndroidとiOSのいずれも報告用のインタフェースを備えていますが、正確性はファームウェアが正しく値を記入することに依存します。報告値と実測が食い違えば、補正はかえって不一致を拡大させます。
そのためOEM側には見落とされがちな作業があります。報告値の校正です。高速カメラで画面とイヤホン出力の同期信号を撮影し、実遅延を測定してファームウェアへ書き込みます。
ゲームモードは事情が異なります。多くのゲームは映像の遅延補正を行わず、エンジン自身の音声バッファに依存しています。したがってゲーム用途ではリンク遅延を下げるしかなく、補正は機能しません。これがゲーミングイヤホンのメーカーがコーデックとバッファ戦略を重視する理由です。
物理的な上限もあります。無線リンクはどれほど最適化しても十数ms以上の伝送と復号のオーバーヘッドが残り、20ms以内が求められる用途は現時点では実現できません。
低遅延方式のOEM実装
低遅延イヤホンのOEM案件で重要なのは、立ち上げ時に遅延目標を数値化することです。RFQでは次の四項目を明確にすることを推奨します。
- ターゲットシーンの遅延上限、80msか40msか
- 対象となる送信側のリスト、どのスマートフォンとOSをカバーするか
- 送信側が専用コーデックに非対応の場合のフォールバック戦略
- 干渉環境で許容できる音割れ率
認証とライセンスのコストも事前に算出する必要があります。aptXとLDACにはライセンス料と認証試験が必要で、LE Audioには新しいプロトコルスタックの認証が要ります。これらはBOMと納期に直接影響します。
Aurora Soundを選ぶ理由
Aurora Sound（深セン北極之声科技有限公司）は深セン北極之光科技有限公司の出資により設立された、深セン拠点のオーディオOEM/ODM源流工場です。
低遅延の分野で当社の設計経験が集中しているのは次の三つです。
- バッファ戦略の最適化で、対象となる送信側の機種ごとに段階設定を行い遅延と耐干渉を両立
- 音声遅延の報告値を実測で校正し、プレーヤーの補正を実際に機能させる
- Bluetoothと2.4GHz独自リンクのハイブリッド設計で、配信とカラオケをカバー
よくある質問 FAQ
Q：Bluetoothイヤホンの遅延はどれくらいで気になりますか？A：シーンによって変わります。動画視聴では音と映像のずれの知覚閾値は約80-125msで、音が映像より遅れる方が先行するより気づかれやすくなります。対戦型ゲームでは60msを超えると銃声と画面の対応感が損なわれます。リズムゲームは40ms以内が求められます。音楽を聴くだけなら視覚的な参照がないため、遅延は体験に影響しません。
Q：aptX Adaptiveの遅延は本当に50msまで届きますか？A：公式の公称値は50-80msで、前提として両端がこのコーデックに対応し無線環境が良好である必要があります。実測ではAndroid機による差が大きく、機種によってはファームウェアが追加のバッファを持ち込むため、実測値が80-120msに落ち着くこともあります。スマートフォンが非対応ならSBCまたはAACにフォールバックし、遅延は150-250msに戻ります。
Q：LDACとaptXはどちらを選ぶべきですか？A：目的によります。LDACは高ビットレートを前面に出し、最高990kbps、96kHz/24bitで、音質を訴求するリスニング製品に向きます。ただし無線の負荷が大きく干渉環境では自動で段階を落とし、遅延は通常150ms以上になります。aptX Adaptiveは動的ビットレートと低遅延が主眼で、ゲームと動画により適しています。ターゲットユーザーがiOS中心ならどちらも適合しないため、AACの最適化を主軸にすべきです。
