Use larger capture pipe since we support resampling by 6:1

This avoids overruns on the client AudioRecord side,
without requiring client to use a large buffer.
It should not increase input latency, since a newly started AudioRecord
always joins the stream starting at the latest data.

Change-Id: Ib2b8de75cc40a6a3d493a1f8b46b41220f69264f

1 files changed, 3 insertions, 3 deletions

diff --git a/services/audioflinger/Threads.cpp b/services/audioflinger/Threads.cpp
index b3d1dbe..54853a5 100644
--- a/services/audioflinger/Threads.cpp
+++ b/services/audioflinger/Threads.cpp
@@ -5555,12 +5555,12 @@ void AudioFlinger::RecordThread::readInputParameters_l()
     mBufferSize = mInput->stream->common.get_buffer_size(&mInput->stream->common);
     mFrameCount = mBufferSize / mFrameSize;
     // This is the formula for calculating the temporary buffer size.
-    // With 3 HAL buffers, we can guarantee ability to down-sample the input by ratio of 2:1 to
+    // With 7 HAL buffers, we can guarantee ability to down-sample the input by ratio of 6:1 to
     // 1 full output buffer, regardless of the alignment of the available input.
-    // The "3" is somewhat arbitrary, and could probably be larger.
+    // The value is somewhat arbitrary, and could probably be even larger.
     // A larger value should allow more old data to be read after a track calls start(),
     // without increasing latency.
-    mRsmpInFrames = mFrameCount * 3;
+    mRsmpInFrames = mFrameCount * 7;
     mRsmpInFramesP2 = roundup(mRsmpInFrames);
     delete[] mRsmpInBuffer;
     // Over-allocate beyond mRsmpInFramesP2 to permit a HAL read past end of buffer