Fix audio capture buffer handling on Android.

Fix audio capture buffer handling on Android.

The buffer handling in OpenSL is:
1. enqueue the buffers;
2. wait for a callback;
3. inside the callback, read out the PCM data of current buffer and enqueue one buffer (it's the same buffer in this case).
4. go to step 2.

Current implementation has several problems:
a. When buffer #1 (not buffer #0) is read first time, it doesn't have PCM data recorded by the device. 
b. There are 2 buffer worth of time delay.
c. There are racing condtion since both OpenSL and AudioInputController hold the same buffer.

BUG=243506
R=xians@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=202581

[wjia(left Chromium), 2013-05-28 00:12:07]

ping.

[no longer working on chromium, 2013-05-28 09:13:05]

On 2013/05/28 00:12:07, wjia wrote:
> ping.

Sorry I missed this thread.

lgtm, thanks for fixing it.

Curiously, do you experience real audio problem because of the existing code?

a and b, True, I agree with your comments, we are having unnecessary 2 buffers'
delay in the setup time.

c. I am not sure if it will make any difference on the behaviours, the callback
is called synchronously by the soundcard internal thread, so OpenSL won't write
to the buffer until the callback returns.

Correct me if I am wrong.

[wjia(left Chromium), 2013-05-28 16:32:51]

Committed patchset #1 manually as r202581 (presubmit successful).

[wjia(left Chromium), 2013-05-28 17:07:45]

On 2013/05/28 09:13:05, xians1 wrote:
> Sorry I missed this thread.
> 
> lgtm, thanks for fixing it.
> 
> Curiously, do you experience real audio problem because of the existing code?
> 
> a and b, True, I agree with your comments, we are having unnecessary 2
buffers'
> delay in the setup time.
> 
> c. I am not sure if it will make any difference on the behaviours, the
callback
> is called synchronously by the soundcard internal thread, so OpenSL won't
write
> to the buffer until the callback returns.
> 
> Correct me if I am wrong.

We shouldn't count on any specific (or detailed) implementation of underneath
modules. If you read chapter 3.3 Notifications in OpenSLES spec 1.0.1, it says
"The context from which the callbacks are invoked is undefined, and typically
implementation- and OS-dependent.".

I was even thinking about moving the call of Enqueue onto a Chromium thread. But
that would require more buffers to prevent buffer underrun due to thread
switching taking some time. So I will keep an eye on the future report of any
problem which would be resulted from calling API functions on callback thread.