[openal] openSL backend

[Chris Robinson]

On 01/21/2014 03:21 AM, Philippe Simons wrote:
> I'd like to enable low-lantency output on android.
>
> For this, the user should request a specific Frequency and UpdateSize when
> creating the context.
>
> Currently the OpenSL implementation, override these with hardcoded values.
> I've commented this code to let it uses the values set
> by UpdateDeviceParams(), and it seems to works fine on my devices.
>
> My question is, why is there hardcoded values in the OpenSL implementation,
> and can it be safely removed?

They were hardcoded to try to avoid compatibility problems. I don't know 
what Android/OpenSL is capable of, and I can't test the OpenSL code 
myself to know how to react to incompatible settings (e.g. 
unknown/unsupported sample rate or buffer size).

Reseting the device is particularly touchy because if it doesn't set 
something usable, the device gets marked as disconnected and basically 
becomes unusable. The backend's reset method has to be as foolproof as 
possible, and has to get the underlying device in a known and usable 
state as best it can, regardless of whatever the initial parameters may 
have been.

If you believe your code is robust enough to deal safely with that, 
though, I can take a look.

In regards to UpdateSize, however, that shouldn't be controlled by user 
parameters. The device period/mix size is currently linked to the 
refresh, but that may change. At most, NumUpdates should scale if the 
playback frequency needs to change -- e.g. if you request 32khz playback 
with 2 updates, and you get 48khz playback, the number of updates should 
increase to 3 so that it takes about the same amount of time to play the 
whole buffer.