ESP32 esp-idf bluetooth a2dp_sink への aptx decode 実装の考察 #2

では、OI_CODEC_SBC_DecodeFrame() は、どこでコールされているか、逆にトレースしてみましょう。

bt/bludorid/btc/profile/std/a2dp/btc_a2dp_sink.c の btc_a2dp_sink_handle_inc_media() にありました。

bt/bludorid/btc/profile/std/a2dp/btc_a2dp_sink.c
629 static void btc_a2dp_sink_handle_inc_media(tBT_SBC_HDR *p_msg) ... 651 APPL_TRACE_DEBUG("Number of sbc frames %d, frame_len %d\n", num_sbc_frames, sbc_frame_len); 652 653 for (count = 0; count < num_sbc_frames && sbc_frame_len != 0; count ++) { 654 pcmBytes = availPcmBytes; 655 status = OI_CODEC_SBC_DecodeFrame(&btc_sbc_decoder_context, (const OI_BYTE **)&sbc_start_frame, 656 (OI_UINT32 *)&sbc_frame_len, 657 (OI_INT16 *)pcmDataPointer, 658 (OI_UINT32 *)&pcmBytes); 659 if (!OI_SUCCESS(status)) { 660 APPL_TRACE_ERROR("Decoding failure: %d\n", status); 661 break; 662 }

同じように、コール元を逆に辿ってみます。
やり方は、esp-idf/components/ ディレクトリーで
$grep -rnH xxxx ./
か、eclipse で、esp-idf/components/ をインポートして、検索します。

btc_a2dp_sink_handle_inc_media() | call btc_a2dp_sink_data_ready() line 472 btc_a2dp_sink_handle_inc_media(p_msg); | call btc_a2dp_sink_task_handler() line 231 btc_a2dp_sink_data_ready(NULL); | event call btc_a2dp_sink_startup() line 264 xTaskCreatePinnedToCore(....) | call bt/bluedroid/btc/profile/std/a2dp/btc_av.c: btc_av_init() line 972 stat = btc_a2dp_sink_startup(); | call 1 btc_a2d_sink_init() line 1459 return btc_av_init(....) btc_av_init() | call 2 btc_a2d_src_init() line 1492 return btc_av_init(....) | call btc_a2dp_call_handler() line 1368 btc_a2d_sink_init(); line 1394 btc_a2d_src_init(); | call btc_task.c table definition line 54 ststic btc_func_t profile_tab[BTC_PID_NUM] = { line 80 [BTC_PID_A2DP] = {btc_a2dp_call_handler,btc_a2dp_cb_handler},

最終的には、テーブルでのスタティックな定義になります。

ここで、aptx,aptx-hd decode 実装の方法を、考えてみましょう。

大雑把に言えば、bt/bludorid/btc/profile/std/a2dp/btc_a2dp_sink.c の
line 629 static void btc_a2dp_sink_handle_inc_media(tBT_SBC_HDR *p_msg)
で、コーデックを SBC decode から、APTX(-HD) decode に変えれば、なんとなくできそうです。

bt/bludorid/btc/profile/std/a2dp/btc_a2dp_sink.c
629 static void btc_a2dp_sink_handle_inc_media(tBT_SBC_HDR *p_msg) ... 655 status = OI_CODEC_SBC_DecodeFrame(&btc_sbc_decoder_context, (const OI_BYTE **)&sbc_start_frame, 656 (OI_UINT32 *)&sbc_frame_len, 657 (OI_INT16 *)pcmDataPointer, 658 (OI_UINT32 *)&pcmBytes);

655 OI_CODEC_SBC_DecodeFrame() コール を、aptx,aptx-hd コーデックの場合は APTX Decodeルーチンコールに変える。

もし、aptx decode を、esp-idf (フレームワークみたい) に組み込むとすれば、SBC に習って、
bt/bludroid/external/aptx/decoder/src/
あたりに、組み込む構成になるのか。

残された問題は、Bluetooth A2DP SOURCE から送られてくる、コーデックの判定方法になります。

これは、 Andoriod スマホとペアリングした時、または、スマホで、bluetooth スピーカ のコーデックを変更したときに、ソースとシンクで、構成情報のネゴシエーションを行うと思うので、
ESP32(a2dp_sink プログラムを書き込んた) を USB Serial で PC と繋げて、シリアルターミナルにログが吐き出される状態にして、実際にAndoroid スマホとペアリングしてみます。
その時のログをチェックしてみて、構成情報のネゴシエーション処理している場所の当たりを付けてみることにします。

では、早速確認してみます。と言いたい所ですが、それをするには、Andoroid Version8.0 以降のスマホが必要ぞね。

じゃが、生憎、おんちゃんのスマホは、Andoroid Version5.0 ぞね。
と言うわけで、これから先は、新しいスマホを買う迄、しばらくお預けじゃ。

じゃが、しかし。google で、色々検索していたら、Bluetooth 4.0 USBアダプタ(class1) MM-BTUD43 なるものがありました。
これだと、1,482円 で買えそうなので、こちらでも大丈夫か。

早速購入して、Windows10 で試してみましたが、残念ながら、Windows10 の Bluetooth のデバイス一覧に出てこないので、ペアリングも出来ませんでした。
その後、使えるようになりました。
Windows10 の "Bluetooth と その他のデバイス" > +Bluetooth またはその他のデバイスを追加する
で、追加しないといけなかったみたいです。

CentOS7 の方では、問題なくペアリングできました。
但し、選べるプロファイルには、High Fidelity Playback(A2DP Sink) だけ表示されます。
どうやら、esp32 の a2dp_sink の方から、APTX のプロファイル情報を返さないとだめのようです。