Bluetooth® LEで音声通信にトライ！ LE Audioを試してみた②　ブロードキャスト

今回は、LE Audioが備えるブロードキャスト機能である「AURACAST™」を試してみます。
特定エリアにおいて、1つのソースから不特定多数者に対し情報発信できるという特徴があるので、例えば以下のような用途で活用できそうです。

+ 会議室内多言語音声発信
国際会議などでは、話者のスピーチを複数の言語に翻訳し、多数の人にそれぞれ対応した言語版の内容を伝える必要があります。ブロードキャストにより同時多数の受信が可能になります。
+ 公共エリアのサイレント･スクリーン用音声
駅や空港の待合室などに設置されているスクリーン（TV、ディスプレイ･パネルなど）のスピーカー音量は、あまり大きくできないかもしくはオフされています。スクリーン機器側にブロードキャスト放送機能があれば、手持ちのブロードキャスト用レシーバで音声を選局受信することで、誰でも自由にスクリーン映像と合わせて視聴できるようになります。
+ ツアーガイド用音声アシスト
旅行添乗員が観光案内･説明や誘導案内をする際、ツアー客全員に確実に聞こえるようにする必要があります。ツアー客ひとりひとりにブロードキャスト用レシーバを渡しておけば、多少離れていても楽に伝えることができます。

![000_picture_.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/a11b956b-300c-7c5d-0803-88f573a233ea.png)



前回記事はこちら:
<a href=https://qiita.com/ykawano/items/eef0866616ff68122ed8>Bluetooth® LEで音声通信にトライ！ LE Audioを試してみた①　ユニキャスト</a>

当記事での試行環境は、ハードウェア･ソフトウェアともに前回と同じなので、そのまま行えます。

# 1．ハードウェアの準備

【用意するもの】
前回記事と同じものを用意します。
+ <a href=https://www.st.com/ja/evaluation-tools/stm32wba55g-dk1.html>STM32WBA55G-DK</a>　x2台
+ USB Type-Cケーブル x2本
+ パソコン
+ イヤホン or ヘッドホン（有線）
+ ポータブル音楽プレーヤー
+ 3.5mmステレオ･ミニプラグ･ケーブル
+ モバイル･バッテリ
+ LE Audio対応スマートフォン（ここではGoogle Pixel7を使用）
+ LE Audio対応ワイヤレス･イヤホン（ここではearfun Air Pro4を使用）

# 2．ファームウェアの準備
前回記事と同じTMAP用ファームウェアを使います。同じ手順で書き込みしますが、既に書き込み済みであればそのまま使えます。
→ <a href=https://qiita.com/ykawano/private/eef0866616ff68122ed8>記事①</a>「2.ファームウェアの準備」参照

ブロードキャスト通信も、前回記事と同じ**TMAP（Telephony and Media Audio Profile）** 用ファームウェアで試すことができます（モードを切り替えて使うことができます）。ファームウェア･フォルダを見回すと **PBP（Public Broadcast Profile）** 名のファイルも確認できます。こちらはブロードキャストのみ試せるものですが、今回は使用しません。

![201_FWfolder.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/1e68c24d-a9cc-b3ac-c549-5965eefbaa90.png)




#### 補足説明1 Profile

フォルダ内にあるファームウェアのネーミングについて、ちょっと違和感があるかもしれません。デバイスを区別する呼称が異なるため、少し迷います。
関連しますが、LE Audioの説明書を読む中で混乱を生むことのひとつに、
「デバイスの各役割の呼び名（Role名）が、説明の立ち位置によっていろいろと変わる」
が挙げられます。
どのProfileの中で、どのRoleの話をしているのかで変わるようです。


この記事内でどのワードを使えばよいのか迷いましたが、PBPのRoleのひとつである“Broadcast Assistant”名が本記事内で登場する場面もありましたので、PBPで使われている **“Source”** （Central）と **“Sink”** （Peripheral）を使います。

<table>
  <caption> HAP/PBP/TMAPの各Role名 </caption>
  <thead>
    <tr>
      <th>ユースケース･ <BR> プロファイル</th>
      <th>Role名</th>
      <th> 使用例 </th>
    </tr>
  </thead>
  <tr>
    <td rawspan="3"> HAP: <BR> Hearing Access Profile <BR></td>
    <td> Hearing Aid <BR> Hearing Aid Unicast Client <BR> Hearing Aid Remote Controller <BR>Immediate Alert Client</td>
    <td>  補聴器（Hearing Aid） </td>
  </tr>
  <tr>
    <td rawspan="3"> PBP: <BR>Public Broadcast Profile</td>
    <td> Public Broadcast Source <BR> Public Broadcast Sink <BR> Public Broadcast Assistant</td>
    <td> 会議用多言語音声発信 <BR>サイレント･スクリーン用音声<BR>ツアーガイド用音声アシスト</td>
  </tr>
  <tr>
    <td> TMAP: <BR> Telephony and <BR> Media Audio Profile</td>
    <td> Call Gateway <BR> Call Terminal <BR> Unicast Media Sender <BR> Unicast Media Receiver <BR> Broadcast Media Sender <BR> Broadcast Media Receiver </td>
    <td> Call → ヘッドセット<BR>Unicast → ワイヤレス･スピーカ、イヤホン<BR>Broadcast →上段のPBPと同じ </td>
  </tr>

</table>

Bluetooth Low Energy（BLE）のコアベース（GAP: Generic Access Profile）で、コネクション接続において話をすると、“Central”（マスター）と“Peripheral”（スレーブ）が基本的な呼び名になります。TMAP用のファームウェアでは、“Central”や、“Peripheral”名がこのProject内のファームウェア名として使われています。TMAPを使うケースではProfile名にある“Sender”&“Receiver”を使いたいところですが、他に“Gateway”&“Terminal”といったRole名もありかえって混乱します。ここは基本に戻って“Central”&“Peripheral”を使った方が無難です。一方、PBP用、つまりブロードキャスト専用ファームウェアにおいては、“Sink”&“Source”という名前が使われています。

#### 補足説明2 仕様書では？

ProfileやRoleについて、Bluetooth仕様書を見て私が理解できた範囲で図示しておきます。一部は仕様書内の図からそのまま引用したものになってます。CAPやBAP（両方ともオーディオ用のProfile）などは、本記事内の後の説明でも登場しますので、ここで軽く押さえておいた方が良いでしょう。仕様書にはProfile（& Protocol）、Rolesなどの正しい説明がされていますので、詳しく知りたい方はそちらを参照してください。こちらにドキュメント一覧があります → <a href=https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/le-audio/le-audio-specifications/>LE Audio仕様</a>
ここでは、「こういう風に構成されているんだな」と眺める程度で問題ありません。



##### Bluetooth LE Audio stack

LE Audioを構成するための、ファームウェア･階層構造図です。上段のUse Case Profileは、どんな用途で使うのか、つまり最終的なアプリケーション用（補聴器、ヘッドセットなど）のProfileになります。その下にオーディオ担当のProfileが多数配置されてますが、少し複雑そうなのでここではCAPとBAPだけ触れる程度にします。BAPがオーディオ･ストリーム部分などを担い、CAPはオーディオ基本部分全体を取りまとめている、などと理解する程度で十分です。
なおこの図では、LC3コーデック部分と、Bluetooth Core部分（GAP）は省略しています。

+ CAP（Common Audio Profile）: BAPの他、MCP（メディアコントロール）やVCP（ボリュームコントロール）などのオーディオ基本Profile全般取りまとめ
+ BAP（Basic Audio Profile）: オーディオストリーム、再生開始･停止、ユニキャスト･ブロードキャストなどのコントロール

![203_BluetoothStack_LEaudio_.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/6fe7bc16-9f35-484a-cdf7-d6f0477c2ddc.png)


##### Bluetooth LE Audio Roles

ユニキャストとブロードキャストでの、基本的な役割設定を整理します。下図はBluetoothガイドブックからの引用（一部）ですが、“C” & ”P”、"B" & "O"はそれぞれ、Core ProfileであるGAP（Generic Access Profile）で定義された、"Central"と"Peripheral"（ユニキャスト時）、"Broadcaster"と"Observer"（ブロードキャスト時）を意味します。ここまではBluetooth機器全般で共通です。これらをオーディオ用途のProfileで考えた場合、つまり上位層ProfileであるCAPやBAPで見た場合、下図のようにRole名が変化します。

![205_C-P_B-O_.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/a3767f1e-df48-1b6b-ce6d-01241bed9cc0.png)



CAP: Common Audio Profile
BAP: Basic Audio Profile
Core（=GAP）:Generic Access Profile

# 3. 動作確認1 ボード間通信

まずは、準備した2台のSTM32WBA55G-DKボードを使って通信を行います。

## セットアップ

ボードのセットアップ･接続方法は、前回記事内の“動作確認1”と同じです。
→ <a href=https://qiita.com/ykawano/private/eef0866616ff68122ed8>記事①</a>「3. 動作確認1　> 接続」参照

![301_setup_.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/52088e39-29cc-3896-9626-a311c0af2ff2.png)




## 操作手順

以下手順で両ボードを操作します。
送信側の音楽再生開始はどのタイミングでも大丈夫です。

![302_LCD_connection1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/3ea6febd-13f7-086f-23e3-546e229498ee.png)



## 音声確認

記事①の時と同様、問題なく音声確認できました。デフォルトのサンプリング周波数設定は48KHzですが、Source側のスタート時のメニュー内で、他に32KHz、24KHz、16KHz、8KHzが選択できます。


見ると明らかですが、やっている内容としては記事①の“動作確認1”と同じで、Source（Central）から送信した音声をSink（Peripheral）で受信する動きなので、特に変わりません。
ただ、コネクションされていなため、Source側は音声信号を垂れ流ししている状況となります。Sink側を電源オフさせたり、遠い場所に離して通信が切れたりしたとしても、Source側は変わらず送信（ブロードキャスト）を続けます。通信が切れた場合、Sink側は「Scanning nearby sources」のメニューに戻ります。再度エリア内に入るとSource名（デバイス名 = 放送局）が表示されるので、ここでキーを押すと再び受信できます。

## 複数Source

（実際に確認する際はSTM32WBA55G-DKが3台以上必要です）
ブロードキャストは「1対多受信」なので、基本的に多数の受信デバイスを想定していますが、逆に送信側が複数あっても特に問題ありません（1エリアに存在できるSourceデバイス台数については制限があると思います）。この場合、放送局を選択して受信する、まさにラジオのような使い方ができます。

![303_source_x.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/8b62867e-3f8c-0b60-e08b-dcf9301cfb5a.png)




# 4. 動作確認2 with ワイヤレス･イヤホン

次にSource（Central）側としてSTM32WBA55G-DKボードを使い、Sink（Peripheral）側としてLE Audio対応のワイヤレス･イヤホンを使います。イヤホン側の操作は通常、スマートフォンのアプリで行います。

## セットアップ

Source側ボードは動作確認1と同様にUSB電源とオーディオ機器を接続します。次にスマートフォンとワイヤレス･イヤホンをBluetooth接続しておきます。今回、スマートフォンは“Broadcast Assistant”として機能します。
スマートフォン: Google Pixel7
ワイヤレス･イヤホン: earfun Air Pro4

![401_setup_.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/b5002c22-08e6-9bda-5993-500834359a96.png)


PAST: Periodic Advertising Synchronisation Transfer

#### 補足説明3
ユニキャストの時と比べると情報のやりとりが複雑なので、図で示します。
CAPやBAPなどの意味については本記事内の<a href="#補足説明2-仕様書では">補足説明2</a>を参照してください。
各デバイスは動作モードによって定義されるいくつかのProfile（CAPやBAPなど）の中で役割を決められます。ユニキャストのような1対1接続の場合送り手側と受け手側の役割だけで済みますが、ブロードキャストの場合、中間操作を行うアシスタント的な役割が必要になるケースがあります。この例では、スマートフォンがそのアシスタントとしての役割を担います。

![402_broadcast_figure_.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/deb21641-a8ea-cb6a-2bf1-2713d0bbe707.png)



CAP: Common Audio Profile
BAP: Basic Audio Profile
BIS: Broadcast Isochronous Stream
ACL: Asynchronous Connection-oriented Link

下図は、補足説明2「Bluetooth LE Audio Roles」のところで解説したRole図と内容的には同じです。<a href="#bluetooth-le-audio-roles">前の図</a>はあくまで基本形でしたが、実際の使用ケースとしては下図右側ようなブロードキャストの形も可能です。むしろ、この形で利用されるケースが多いと思われます。この記事はLE Audioの話なのでオーディオ前提で解説を進めており、CoreベースのRole名を使うとややこしくなるので、今回の図ではBAPのRole名でイニシャル表記しました。例えば、“B”（Broadcaster）や“O”（Observer）の代わりに“So”（Source）と“Si”（Sink）を使っています。

![403_broadcast_unicast_profile.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/8636527a-e733-3444-6469-d49f0666bf99.png)



最初にイヤホンとスマートフォンを接続した場合、通常この2機器間での音声･情報のやりとりになるのでユニキャスト･モードになります（上図左側）。ブロードキャスト･モード（= AURACAST）として動作させる場合、この状態から、音声ストリームを変更する必要があります。ここでスマートフォンの役割がUnicast Client（“C”）から、Broadcast Assistant（“A”）へ変わります。
この時、音声データ受信用の設定情報などを、新たに登場したBroadcast Source（“So”）から受け取って、それをイヤホンなどのBroadcast Sink（“Si”）に橋渡しします。同時にイヤホンの方もUnicast Server（“S”）からBroadcast Sink & Scan Delegator（“Si”）にチェンジします。




## 操作手順

以下手順で、Source側ボードとスマートフォンを操作します。

![410_LCD_connection1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/9e223c4e-bd13-9175-449b-4b93505404a4.png)


スマートフォン側操作例

![420_pixel7_control.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/360475/6eba378b-6a8b-db02-82e8-432757728c7d.png)



## 音声確認

こちらも問題なく音声確認できました。
STM32WBA55G-DK同士での実験時は、48KHzサンプリング設定の他に32KHz、24KHz、16KHz、8KHzでも試聴できましたが、今回の環境では48KHzのみ動作しました（他の設定だとAURACASTモード自体がリセットされるか、同期しても音がきこえてこない）。サポート設定範囲の問題かと推察しています。


## その他確認

その他、ブロードキャスト（AURACAST）使用時に想定される実験をしてみました（*1）。


##### ･スマートフォン音楽再生中に、AURACASTをオンにするとどうなるか

結果
そのままスマートフォンから流れる音楽が継続し、AURACASTへスイッチされませんでした。一度音楽を停止してAURACSTをオンすると接続できます。


##### ･AURACAST音楽再生中に、スマートフォン上の音楽を再生させるとどうなるか

結果
そのままAURACASTから流れる音楽が継続し、スマートフォンへスイッチされませんでした。AURACAST接続をいったん解除する必要があります。解除後、スマートフォン側の音楽を再生すると接続できます。解除するにはAURACAST設定画面のページまでいかないとダメなので、少々面倒です。



##### ･AURACAST音楽再生中に、電話がかかってきたらどうなるか

結果
スマートフォン側が着信すると、イヤホンから聴こえる音楽はフェードアウトして（着信音がオン設定の場合）着信音でお知らせします。通話終了後は、元のAURACAST放送受信を自動再開しました。


*1 注記:
上記3つの実験時の挙動は、Source側のSTM32WBA55G-DKボードおよびファームウェアとは直接関係しないと思われます。Androidバージョン仕様によるものなのか、もしくは使用したスマートフォンとイヤホン依存の可能性があります。参考程度としてください。