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