Fix underruns when fast track denied due to SRC

OpenSL ES requests a fast track.  If sample rate conversion is needed,
the request is denied by server, and a larger client buffer is used
to handle the higher latency of a normal track.  However the client
notification period was calculated based on buffer being divided into
2 sub-buffers.  That resulted in the notification period being too long.
The server pulls chunks that are smaller than half the total buffer.
So now the client uses 3 sub-buffers when there is SRC.

Also removed the 'defer wake' optimization because it was incorrect.
This optimization attempted to reduce the number of wakeups of client,
when server releaseBuffer knows that another releaseBuffer will be
following.  But there is no way for the first releaseBuffer to predict
how soon the second releaseBuffer will occur.  In some cases it was
a long time, and the client underran.  So now the client is woken up
immediately if the total number of available frames to client is >=
the minimum number the client wants to see (the notification period).

Also fix bug where minimum frame count was not being used in the
calculation of notification period.

Bug: 10342804
Change-Id: I3c246f4e7bc3684a344f2cf08268dc082e338e2a

1 files changed, 0 insertions, 2 deletions

diff --git a/include/private/media/AudioTrackShared.h b/include/private/media/AudioTrackShared.h
index ad7409d..fe258ad 100644
--- a/include/private/media/AudioTrackShared.h
+++ b/include/private/media/AudioTrackShared.h
@@ -383,8 +383,6 @@ public:
 protected:
     size_t      mAvailToClient; // estimated frames available to client prior to releaseBuffer()
     int32_t     mFlush;         // our copy of cblk->u.mStreaming.mFlush, for streaming output only
-private:
-    bool        mDeferWake;     // whether another releaseBuffer() is expected soon
 };
 
 // Proxy used by AudioFlinger for servicing AudioTrack