更新: Android のこのバグは、4.2.2 以降および 5.01 以前のどこかで修正されました。5.01 では、コールバックはドキュメントに記載されているとおりに機能します。
read開発者の近視眼のためにブロックされているようです。
基本的に、オーディオ レコーダーが初期化されると、一種のリング バッファーが割り当てられます.start()。
次に.read()が呼び出されると、バッファー サイズ (または要求されたサイズのいずれか小さい方) の半分まで読み取り、戻ります。
1000 個のサンプルを読み取りたいが、使用可能なサンプルが 900 個しかない場合、戻る前にさらに 100 個のサンプルを待機する必要があります。ただし、1000 を超えるサンプルがある場合は、それらを即座に読み取り、すぐに戻ります。
理想的には、非ブロッキング読み取りを提供して、利用可能なものはすべて返されるか、完全な読み取りに相当するデータがいつ利用可能になるかを知る方法を提供して、非ブロッキング読み取りを実行できるようにします。
彼らが最初のものをサポートしているとは思わない。set period コールバック メソッドを使用して秒をサポートしようとしているように見えますが、これまでのところ、迅速なノンブロッキング読み取りを実行するための正しいタイミングでコールバックを取得できません。
ネイティブ C++ ソース コードの完全なソース (8.5G バイト) を複製し、すべてのレイヤーで機能を追跡して、どのように機能するかを確認しようとしています。
非ブロッキング.read(0)ing の秘訣は、完全な読み取りに相当するサンプルの準備が整ったときにのみ読み取ることです。しかし、その条件がいつ真であるかを判断することは、私がまだ理解していないことです.
参照: ネイティブ C++ 関数を呼び出す .read() の Java コードは次のとおりです。
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.3.4_r1/android/media/AudioRecord.java#AudioRecord.read%28java.nio.ByteBuffer% 2Cint%29
上記の read() メソッドは、次の場所にあるネイティブnative_read_in_direct_buffer()を呼び出します。
http://pdroid.googlecode.com/svn/android-2.3.4_r1/trunk/frameworks/base/core/jni/android_media_AudioRecord.cpp
(私が知る限り)どの呼び出しまたはポイントがandroid_media_AudioRecord_readInByteArray()順番に呼び出さAudioRecord.read()れ、この関数には do/while ループがあり、必要なバイト数が読み取られるまで (またはバッファーサイズの半分、frameworks/base/media/libmedia/frameworks/base/media/libmedia/AudioRecord.cpp小さい方。）
私はコールバックをうまく機能させようとしましたが、 read() が戻る前にオーディオバッファがいっぱいになるのを待たなければならないときにのみコールバックするようです-それで、ポイントは何ですか.
私の次の目標は、通知コールバックのソース コードを突き止めて、それがいつ何をするのかを正確に推測できるようにすることです。