[openal] [Extensions]Distance_delay_mode

Fri May 5 17:13:01 EDT 2023

Hello all,

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.
>

Reviewing the specification it is not indicated explitily AL_SOURCE_STATE
be a read-only parameter, it's clear is used for Source State Query as
indicated on page 42 for alGetSource and we are implicitly assuming its use
(as query-only). Is not listed in the previous section (4.3.2. Source
Attributes) but you can see AL_SOURCE_TYPE explicitly indicated as
read-only.

On the other hand, in the Creative OpenAL Programmer's Guide we can see
this parameter as set property for alSourcei (pages 12 and 42 again), but
in the source code of old windows implementation from creative is indicated
as read only too.

case AL_SOURCE_STATE:
// Query only
alSetError(AL_INVALID_OPERATION);
break;

so in a first approach, there is no reason to cannot take this token for a
new feature in a specific implementation.

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.
>

 Historically, in OpenGL some of the first new hardware features were
performed using  glEnable and glDisable calls, adding new properties (pure
additive) or disabling previous ones with others richer or more complex.
Using the same philosophy, The AL_DISTANCE_DELAY_MODEL_AAX used in
alEnable/Disable context state allows to disable the old distance models
and switch on the new ones, using the constrain of physical delay due to
the sound speed in the medium. I mean, when

alEnable(AL_DISTANCE_DELAY_MODEL_AAX);

AL_INVERSE_DISTANCE becomes AL_INVERSE_DISTANCE_DELAY_AAX
AL_INVERSE_DISTANCE_CLAMPED becomes AL_INVERSE_DISTANCE_DELAY_CLAMPED_AAX
...
...

changing the computing state at low level like a feature implemented in
real hardware, if I understood well reading the extension and reviewing the
AeonWave code slightly.

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?
>

The feature ability using a new function could be an option. In this case,
the author preferred to do the minimum changes in the code.

El mié, 3 may 2023 a las 14:10, Chris Robinson (<chris.kcat at gmail.com>)
escribió:

>
>
> 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?
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20230505/019b74a4/attachment.htm>