AudioTransport::NeedMorePlayData is no longer called from different threads using OpenSL ES on Andr…

AudioTransport::NeedMorePlayData is no longer called from different threads using OpenSL ES on Android

BUG=webrtc:6476
NOTRY=TRUE

Committed: https://crrev.com/14acf658ad5ae44c45aecfcedfcca066abb9af79
Cr-Commit-Position: refs/heads/master@{#14599}

[henrika_webrtc, 2016-10-11 10:34:02]

Description was changed from

==========
AudioTransport::NeedMorePlayData is no longer called from different threads
using OpenSL ES on Android

BUG=
==========

to

==========
AudioTransport::NeedMorePlayData is no longer called from different threads
using OpenSL ES on Android

BUG=webrtc:6476
==========

[henrika_webrtc, 2016-10-11 10:34:02]

henrika@webrtc.org changed reviewers:
+ aleloi@webrtc.org

[henrika_webrtc, 2016-10-11 10:35:32]

PTAL

[aleloi, 2016-10-11 10:49:39]

Working on it!

[aleloi, 2016-10-11 11:07:33]

I wonder about the implications of this change.

I think the time for the main thread to finish initalization is
possibly reduced, because it doesn't have to wait for 2 frames of
audio.

Could there be any audio quality implications? Would e.g. audio be
20ms delayed because of the two silence frames in the beginning?

Would there be some benefits in asking for the two frames in the first
worker thread call? E.g. set a 'buffer-not-filled' flag at start up,
and check it in FillBufferQueue. If it is first time FillBufferQueue
is called, ask for the two extra audio frames to fill the buffer.

[henrika_webrtc, 2016-10-11 11:30:48]

Good comment but the latency is not affected. I have a unit test that injects
impulses into the audio
and detects when they are "looped back" and measures the latency and it is
identical before and after.
It has been verified on two different devices.

[aleloi, 2016-10-11 13:03:37]

On 2016/10/11 11:30:48, henrika_webrtc wrote:
> Good comment but the latency is not affected. I have a unit test that injects
> impulses into the audio
> and detects when they are "looped back" and measures the latency and it is
> identical before and after.
> It has been verified on two different devices.

In this case, it LGTM!

[henrika_webrtc, 2016-10-11 13:10:56]

Description was changed from

==========
AudioTransport::NeedMorePlayData is no longer called from different threads
using OpenSL ES on Android

BUG=webrtc:6476
==========

to

==========
AudioTransport::NeedMorePlayData is no longer called from different threads
using OpenSL ES on Android

BUG=webrtc:6476
NOTRY=TRUE
==========

[henrika_webrtc, 2016-10-11 13:11:00]

The CQ bit was checked by henrika@webrtc.org

[commit-bot: I haz the power, 2016-10-11 13:11:07]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-10-11 13:15:43]

Description was changed from

==========
AudioTransport::NeedMorePlayData is no longer called from different threads
using OpenSL ES on Android

BUG=webrtc:6476
NOTRY=TRUE
==========

to

==========
AudioTransport::NeedMorePlayData is no longer called from different threads
using OpenSL ES on Android

BUG=webrtc:6476
NOTRY=TRUE
==========

[commit-bot: I haz the power, 2016-10-11 13:15:44]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-10-11 13:15:51]

Description was changed from

==========
AudioTransport::NeedMorePlayData is no longer called from different threads
using OpenSL ES on Android

BUG=webrtc:6476
NOTRY=TRUE
==========

to

==========
AudioTransport::NeedMorePlayData is no longer called from different threads
using OpenSL ES on Android

BUG=webrtc:6476
NOTRY=TRUE

Committed: https://crrev.com/14acf658ad5ae44c45aecfcedfcca066abb9af79
Cr-Commit-Position: refs/heads/master@{#14599}
==========

[commit-bot: I haz the power, 2016-10-11 13:15:52]

Patchset 1 (id:??) landed as
https://crrev.com/14acf658ad5ae44c45aecfcedfcca066abb9af79
Cr-Commit-Position: refs/heads/master@{#14599}