+35
−32
Loading
Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more
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