[openal] openSL backend
chris.kcat at gmail.com
Tue Jan 21 07:20:47 EST 2014
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
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
More information about the openal