[openal] [Extensions]Distance_delay_mode

[Chris Robinson]

On 5/2/23 15:08, Raul Herraiz wrote:
> Recently I added to the ext. repository an extension written by Erik Hofman
> a long time ago
> for AeonWave-OpenAL implementation, that takes into account the delay
> caused by
> the distance between the listener and the sources and the velocity of sound
> (propagation in a elastic medium).
> 
> https://github.com/Raulshc/OpenAL-EXT-Repository/blob/master/AL%20Extensions/AL_AAX_distance_delay_model.txt
> 
> The lack of this feature has been criticized on certain occasions, so it
> would be good to keep
> it in mind as a future improvement.

I've thought about doing something like this, but the logistics keep 
tripping me up. A source's propagation delay is theoretically unbounded; 
a source can be over billions of units away needing a buffer of millions 
of updates between what the source is doing out there right now vs what 
the listener is hearing at a given moment. Even if something like that 
is an unusual edge case, there should probably be some kind of limit on 
the number of buffered changes, necessitating a balance between memory 
use and granularity at a distance with many pending updates (and since 
some implementations may be running real-time, there's restrictions on 
being able to grow buffers on-demand the mixer can use).

Not including the propagation delay for the sound itself helps things a 
bit, since the source and listener velocities will adjust the playback 
pitch as necessary (and the new AL_SOFT_source_start_delay can be used 
to delay the actual start of the sound for distance).

That said, I'm not sure I like the API. For one, it makes 
AL_DISTANCE_DELAY_MODEL_AAX be a value you can set on AL_SOURCE_STATE, 
for a call like

alSourcei(source, AL_SOURCE_STATE, AL_DISTANCE_DELAY_MODEL_AAX);

AL_SOURCE_STATE is supposed to be a query-only property to get whether 
the source is AL_INITIAL, AL_PLAYING, AL_PAUSED, or AL_STOPPED, and 
can't be used to set those states. Being able to set it with 
AL_DISTANCE_DELAY_MODEL_AAX like that is incongruent with its query 
usage. Consequently, it leaves no way to query if it's set, and no way 
to unset it.

It also has AL_DISTANCE_DELAY_MODEL_AAX as a property for 
alEnable/Disable context state. Both of these seem unnecessary when 
distance delay isn't applied without the distance model being set to one 
of the new distance delay modes anyway.

Regarding the distance delay model, I don't think making the delay 
behavior part of the distance attenuation model is the best. It adds 6 
new distance models, one for each inverse/linear/exponent and 
clamped/non-clamped, lacking one for AL_NONE, and requiring more if more 
distance models are added. A dedicated source property would seem to be 
sufficient here (making it per-source even if using the context's 
distance model, in case you want distance delay for some 3D sources and 
not others without a per-source distance attenuation model). So you have 
something like

alSourcei(source, AL_DISTANCE_DELAY_MODE, [AL_TRUE | AL_FALSE]);
...
alGetSourcei(source, AL_DISTANCE_DELAY_MODE, &delayMode);

No need for new distance models or context enable/disable state. 
Alternatively, AL_DISTANCE_DELAY_MODE could perhaps take a value 
relating to the delay time/distance, to optimize for the expected delay 
amount, with 0 not allowing a delay.

The ability to signal a reset or "flush" of the pending delayed property 
changes and jump to the latest properties would make more sense to me as 
a new function, instead of a set-only property.

alSourcei(source, AL_DISTANCE_DELAY_MODEL_AAX, AL_INITIAL);

would become something like

alSourceResetDistanceDelay(source);

Unless AL_DISTANCE_DELAY_MODEL_AAX represents some kind of state that 
changes during playback and can also be queried?