[openal] openSL backend

[Philippe Simons]

The only constraint I'm aware on android is on the Frequency, Channels and
FrameSize, I'm ok with leaving Channels and FrameSize hardcoded, and I'll
add code to check the Frequency value with 44.1 as fallback.

about: UpdateSize, in the current openSL implementation, you are already
changing it in the _reset_ function.

Device->UpdateSize = (ALuint64)Device->UpdateSize * 44100 / Device->Frequency;
Device->UpdateSize = Device->UpdateSize * Device->NumUpdates / 2;
Device->NumUpdates = 2;

Which btw, double the size of the given UpdateSize, since default values
are (Frequency = 44100 and NumUpdates = 4)

May I change UpdateSize by just a bit
ie: UpdateSize is 1024, but I'd like to use 1200?


On Tue, Jan 21, 2014 at 1:20 PM, Chris Robinson <chris.kcat at gmail.com>wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20140121/3cbf1bab/attachment.html>