私は WebRTC ストリーミング アプリに取り組んでいます。アイデアは、マイクから信号をキャプチャし、リアルタイムの C/C++ 処理 (JNI) を実行し、処理された信号をサーバーにストリーミングすることです。アプリがフォアグラウンドにある場合、プロセスは期待どおりに機能します。ただし、アプリがバックグラウンドになった瞬間、または電話をロックすると、遅れが始まります。
優先度を Process.THREAD_PRIORITY_URGENT_AUDIO に設定しましたが、それでも遅れます。ラグを修正する方法について、どんな助けでも大歓迎です。
private class AudioRecordThread extends Thread {
private volatile boolean keepAlive = true;
public AudioRecordThread(String name) {
super(name);
}
@Override
public void run() {
Process.setThreadPriority(Process.THREAD_PRIORITY_URGENT_AUDIO);
Logging.d(TAG, "AudioRecordThread" + WebRtcAudioUtils.getThreadInfo());
assertTrue(audioRecord.getRecordingState() == AudioRecord.RECORDSTATE_RECORDING);
// Audio recording has started and the client is informed about it.
doAudioRecordStateCallback(AUDIO_RECORD_START);
// do some C/C++ processing
long st_time = System.currentTimeMillis();
res = org.webrtc.audio.AudioEngine.processBuffer(100*num_buffers, containerBufferShort);
Log.i("process_time", String.valueOf(System.currentTimeMillis()-st_time));
nativeDataIsRecorded(nativeAudioRecord, bytesRead);
}
}
Update1 : アプリがバックグラウンドにある場合、process_time (C/C++ コードがオーディオ バッファーを処理する時間) が 2 倍になることに気付きました。私はこの行動を理解していません！
Update2 : この動作は Android Emulator では発生しませんが、実際の Android デバイス (OnePlus Nord N200) では発生します。
Update3 : @emandt の提案に従って、フォアグラウンド モードとバックグラウンド モードでの CPU 使用率をプロファイリングしました。CPU 使用率は同じままですが、消費電力は著しく低下します。これは、アプリがバックグラウンドにあるときに CPU クロック速度が制限されていることを示唆している可能性がありますか?
