property_id is the original value with the deferred flag in the msb. If the
call is deferred, that flag is set, preventing it from matching any of the
enums. The property_id_ member has the ID without the flag.
There's no need to explicitly clamp to EFX limits when they're the same as or
more lenient than EAX, which were already validated when set, or when it's
within tolerance of the effect implementation.
Also it's generally better to check once all properties for changes and apply
them all if one is different, rather than checking and setting each member
individually.
To avoid alcProcessContext causing deferred EAX properties to be committed.
This simplifies updates when EAX has been initialized, but never or rarely
used.
Committing now always occurs in EAXSet when the property is non-deferred,
updating the OpenAL object(s) with it (with OpenAL's updates then being applied
based on the context's defer state).
Allocate a base EaxEffect object once for all effect types, instead of
reallocating different derived types on effect changes. The reverb and null
effects have been converted to the new interface, the others are currently
broken/unsupported, but will be restored shortly.
This is the start of the refactoring for holding separable per-version EAX
effects. Currently the effect state is stored in the effect object, which is
instantiated per-type. This makes it impossible for different effects to be
assigned on different EAX versions for a given effect slot (e.g. if the app
sets a Chorus effect on EAX4 Slot0, it would fail to get or set the EAX1/2/3
reverb properties since it's a Chorus effect object).
Seperate per-version effects will allow for switching the OpenAL effect by
switching versions. This will provide an extra benefit in being able to delay
OpenAL effect initialization until some EAX version has been set, avoiding an
extraneous reverb and/or chorus processor for apps that only query some EAX
properties but don't set anything (or which only use Slot0, leaving Slot1 with
a defaulted Chorus effect running).
These used to exist with the now-defunct AL_SOFT_buffer_samples extension, this
just restores those queries without extra baggage.
The sample length query are necessary when handling ADPCM buffers, since the
size/channels*8/bits calculation is incorrect with ADPCM. 'Bits' is usually
reported as 4 since most samples in a block are stored as nibbles, but that's
only approximate and doesn't account for the block header. The average number
of bits per sample in an ADPCM block can't be represented as an integer, so the
more blocks there are stored in the buffer, the more inaccurate the calculation
becomes.
The AL_BUFFER query should only return the buffer that was set on a static
source, but some apps used it to detect when a current buffer of a streaming
source changed instead of AL_BUFFERS_PROCESSED.
ADPCM doesn't seem to be well defined for more than two channels, even though
there doesn't seem to be any issue with simply increasing the channel step over
interleaved data (ffmpeg refuses to create IMA4 or MSADPCM files with more than
two channels, and its decoder behaves oddly different when channels > 2). So
IMA4 and MSADPCM can only safely handle 2-channel UHJ.
There's no problem with muLaw supporting 2-, 3-, or 4-channel UHJ though.
