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

ESP32 esp-idf bluetooth a2dp_sink への aptx decode 実装の考察 の続き、 #8 です。

i2s_write が間に合っていないと言う事が判ったので、
i2s_write() が最速になるように、i2s_config の設定を色々試して、下記の様に変更しました。
app_main()::main.c

APTX の1フレームのデコード済データ長は、 2,688 バイト みたいなので、
同じ値にしたかったのですが、I2S DMA の最大は、1024バイトのようなので、
.dma_buf_len = 672 にしました。
.dma_buf_count は、目一杯にしたかったのですが、取り敢えず、.dma_buf_count = 20 です。

考察  #7 で試した、デコードのデュアルタスクでも、"Packet Dropped" は出なくなりました。
ですが、音は相変わらず、シュシュ、キュリュキュリュ の雑音がかなり入ります。

それでは、オリジナルの、デコード部分のシングル版では、どうなるか、試してみました。
ビンゴ!!
"Packet Dropped" は、出ていません。
音は、シュシュ、キュリュキュリュ の雑音 は無くなりました。

なんだ、i2s_write() が問題だったのか。ですが、残念な事にかなりS/N 比が悪いです。
音のパンチも、デコードのデュアルタスク版に比べて少しだけおとなしくなったように一瞬感じたが、気のせいか。
APTXの本来の音が出ている気がしますが、何分、市販のAPTX対応の機器で、音を聞いたことが無いので判りません。
SBC よりは、断然良い音です。

最後は、何か、あっけない感じです。
色々苦労して、デコードのデュアル化までしたあの労力は、何だったのか!!

それでも、ESP32 240MHz で、シングルのデコードでも、i2s_write() を速めれば、APTX は対応可能だと言う事が判っただけでも良かったです。

最後は、S/N比の悪さを改善しないといけない事は、今後の課題として残りました。

但し、シングル版で、APTX でずっと YouTube で音楽を流していると、
watch dog のログが出てきます。
別に、watch dog が出て来ても良いのですが、過去のSBC の方では、
watch dog になっていなかったような気がします。
おまけに、ずっと、APTX で聞いていると、リセットが生じるみたいなので、
この件を改善したら、ソースを公開しようかなと考えちょります。

もしかしたら、.intr_alloc_flags = ESP_INTR_FLAG_LEVEL3 の所為かもしれませんが、調査は、これからです。

結果:どうやら、BtA2dSinkT タスクが、ぶん回っていて、WatchDog が効かないので、表示されている様です。

後、ノイズは、ホワイトノイズの様です。しかし、Andoroid から SBC で聴くと、こんなノイズは出ません。やはり、APTX のデコード処理に問題があるのか?

以上で、
ESP32 esp-idf bluetooth a2dp_sink への aptx decode 実装の考察は、終わりにしたいと思います。

このブログ記事について

このページは、おんちゃんが2019年2月15日 11:28に書いたブログ記事です。

ひとつ前のブログ記事は「ESP32 esp-idf bluetooth a2dp_sink への aptx decode 実装の考察 #7」です。

次のブログ記事は「Raspberry Pi (Raspbian) C light http server」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

カテゴリ

ウェブページ

サイトナビ