[Openal-devel] Deferred updates with OpenAL Soft

[Chris Robinson]

Hi guys.

Recent commits have added support for deferring source, listener, and 
auxiliary effect slot property changes, using the alDeferUpdatesSOFT and 
alProcessUpdatesSOFT functions which will be part of AL_SOFT_deferred_updates 
when it's finished.

The idea is to behave similar to how alcSuspendContext and alcProcessContext 
work in Creative's hardware driver. That is, changing properties like a source 
and listener's AL_POSITION won't have an immediate affect while the context is 
suspended (after an alDeferUpdatesSOFT() call). Audio continues to be mixed 
and sent to the device, but the sounds will use the properties that were set 
before the call. When updates are processed (after a alProcessUpdatesSOFT() 
call), then all changes will apply at the same time and any further changes 
will apply "immediately".

Currently, deferring updates will also defer explicit state changes, ie, calls 
to alSourcePlay, alSourcePause, etc. Automatic changes, such as the source 
reaching the end of the sound or by the device disconnecting, still occur 
immediately, however. Setting a new byte/sample/sec offset will also be 
deferred. I'm not really sure how the hardware driver(s) behave with these 
things, though (are play/stop/etc calls and setting a new offset deferred? Is 
the changed state reported back right away, or after it's applied? what can be 
said about the order of deferred offset and state changes?).


I know some people have been interested in batched updates even in software, 
particularly for cases where the listener and some/all sources need need to 
move en masse around a new origin point, and avoid the problem of an update 
occuring after the listener position changes but before the sources have all 
been changed (or vice versa). These functions should allow for that, as you 
can call alDeferUpdatesSOFT(); at the start of your sound update routine, do 
all your source/listener/effect changes without worry of "partial updates", 
then call alProcessUpdatesSOFT(); to allow all changes to take effect.

Additionally, the extension is designed for easy fall back to the hardware 
method. Doing something like this:

static void AL_APIENTRY wrap_DeferUpdates(void)
{
    alcSuspendContext(alcGetCurrentContext());
}
static void AL_APIENTRY wrap_ProcessUpdates(void)
{
    alcProcessContext(alcGetCurrentContext());
}

void (AL_APIENTRY*palDeferUpdates)(void) = wrap_DeferUpdates;
void (AL_APIENTRY*palProcessUpdates)(void) = wrap_ProcessUpdates;

...

    if(alIsExtensionPresent("AL_SOFT_deferred_updates"))
    {
        palDeferUpdates = alGetProcAddress("alDeferUpdatesSOFT");
        palProcessUpdates = alGetProcAddress("alProcessUpdatesSOFT");
    }

will allow you to call palDeferUpdates and palProcessUpdates to batch your 
updates, regardless of whether the implementation has the extension or not (of 
course, implementations that don't have the extension and don't defer updates 
using the ALC functions won't batch, but you can't really do anything in that 
case anyway).


So, I'm interested in testing and feedback. If you were interested in such 
functionality, feel free to test it and let me know how it works (look for the 
AL_SOFTX_deferred_updates extension string for now, but it's not "production 
ready". Behavior may change until it becomes AL_SOFT_deferred_updates). If 
there's anything that you think should be changed, let me know about that too.

If you're able to compare behavior with hardware drivers that can use 
alcSuspendContext and alcProcessContext to batch updates, I'd be eager to hear 
about what you find. Any differences in behavior, something not getting 
deferred that should, something being deferred that shouldn't, etc.


Thanks!
- Chris