（この質問は、AndroidのMediaPlayerが再生用のライブストリームを準備するのになぜこれほど時間がかかるのかということに部分的に関連しています。 ）
android MediaPlayerを使用して、さまざまなデバイスで次のオーディオストリームを再生しようとしました：http：//newsstream1.publicradio.org。
最後に、prepare（）メソッドの期間が2.2未満のデバイス（1秒未満）と2.2を超えるデバイス（最大30秒かかる場合があります...）の間に大きな違いがあることに気付きました。
基盤となるオーディオフレームワークに関連していますか？（OpenCore VS StageFright）
誰かがすでにそれを経験しましたか？そして、StageFrightメディアプレーヤーでmp3ストリームを読み取るためのより良い解決策を知っていますか？
さて、掘り下げてみると、ロード時間はMediaPlayerのバッファサイズ（ファームウェアにハードコードされている）に依存し、それを変更するためにできることは何もないという結論に達しました。
一定の時間ではなく、一定量のデータをバッファリングしているように見えます。頭のてっぺんからのさまざまなタイプのNPRストリームのビットレートを知らない人にとって、データは次のようになります。
MPRニュースストリーム：27秒（http://newsstream1.publicradio.org:80/）、64 kbps MPRクラシック音楽ストリーム：15秒（http://classicalstream1.publicradio.org:80/）、128 kbps MPR The Currentストリーム：7秒（http://currentstream1.publicradio.org:80/）、128 kbps PRIストリーム：52秒（http://pri-ice.streamguys.biz/pri1）、32kbps 2つの128kbpsストリームでは、ビットレートとバッファリング期間の間に非常に良好な相関関係があります。
いずれにせよ、Androidはオープンソースであるため、Androidが何をしているのかをいつでも確認できます。残念ながら、prepareAsync()はprepare()ネイティブメソッドであり、バッファ関連のイベントもネイティブプロセスからディスパッチされているようです。
にをアタッチして、バッファ状態に関するより詳細な更新を取得しようとOnBufferingUpdateListenerしましたMediaPlayerか？イベントが配信される速度と、さまざまなストリームの各イベントでバッファーが何パーセント満たされるかを比較することは興味深いかもしれません。これをストリームのビットレートと相互参照できます。32kbpsでの4秒間のバッファリングが、128 kbpsでの1秒間のバッファリングと同じ割合でバッファを埋める場合は、答えが見つかったと思います。
ここから派生。
それほど長くはかからないはずですが、MediaPlayer APIには、asyncPrepare()アプリケーションをスムーズに実行し続けるために使用することをお勧めするメソッドがあります。