Requires having the same format as the last call to alBufferData. Also only
makes sense when given a NULL data pointer, as otherwise the internal data will
be overwritten anyway.
The symbols are still there and exported to retain ABI compatibility, but they
no longer do anything except set an AL_INVALID_OPERATION error. They're also
removed from the function and enum tables, since they're not part of any
supported extension.
Requires the MAP_READ_BIT or MAP_WRITE_BIT flags to be OR'd with the format
upon a call to alBufferData, to enable mappable storage for the given access
types. This will fail if the format requires internal conversion and doesn't
resemble the original input data, so the app can be guaranteed the size, type,
and layout of the original data is the same as what's in storage.
Then alMapBufferSOFT may be called with appropriate bit flags to get a readable
and/or writable pointer to the buffer's sample storage. alUnmapBufferSOFT must
be called when access is finished. It is currently invalid to map a buffer that
is attached to a source, or to attach a buffer to a source that is currently
mapped. This restriction may be eased in the future, at least to allow read-
only access while in use (perhaps also to allow writing, if coherency can be
achieved).
Currently the access flags occupy the upper 8 bits of a 32-bit bitfield to
avoid clashing with format enum values, which don't use more than 16 or 17
bits. This means any future formats are limited to 24-bit enum values, and also
means only 8 flags are possible when declaring storage. The alternative would
be to add a new function (alBufferStorage?) with a separate flags parameter.
They're now decompressed on the fly in the mixer. This is not a significant
performance issue given that it only needs a 512-byte lookup table, and the
buffer stores half as much data (it may actually be faster, requiring less
overall memory).
The latter is a bit more descriptive as f0 is often used to denote the
reference frequency of a filter, so f0norm indicates the normalized reference
frequency (ref_freq / sample_rate).
Given that they're nearly identical, it should be relatively simple to use the
same effect state to process either of them, similar to the reverbs. The big
differences seem to be the delay range (much shorter with flanger) and the
defaults.
Turns out the C version of the cubic resampler is just slightly faster than
even the SSE3 version of the FIR4 resampler. This is likely due to not using a
64KB random-access lookup table along with unaligned loads, both offseting the
gains from SSE.
This will be to allow buffer layering, multiple buffers of the same format and
sample rate that are mixed together prior to resampling, filtering, and
panning. This will allow composing sounds from individual components that can
be swapped around on different invocations (e.g. layer SoundA and SoundB on one
instance and SoundA and SoundC on a different instance for a slightly different
sound, then just SoundA for a third instance, and so on). The longest buffer
within the list item determines the length of the list item.
More work needs to be done to fully support it, namely the ability to specity
multiple buffers to layer for static and streaming sources. Also the behavior
of loop points for layered static sources should be worked out. Should also
consider allowing each layer to have a sample offset.
This reports the same ALSOFT version as alGetString(AL_VERSION), but doesn't
require a current context (which requires a ALCdevice) to call. Do *NOT* use
this version to determine feature support, use the standard interfaces. If you
think you need to use this, you probably don't, and shouldn't.
Now FuMa and ACN channel orders are required, as are FuMa, SN3D, and N3D
normalization schemes. An integer query (alcGetIntegerv) is added for the
maximum ambisonic order.
The context state properties are less likely to change compared to the listener
state, and future changes may prefer more infrequent updates to the context
state.
Note that this puts the MetersPerUnit in as a context state, even though it's
handled through the listener functions. Considering the infrequency that it's
updated at (generally set just once for the context's lifetime), it makes more
sense to put it there than with the more frequently updated listener
properties. The aforementioned future changes would also prefer MetersPerUnit
to not be updated unnecessarily.
Apparently there is a bug with at least MinGW-W64 where fegetenv and fesetenv
do not properly save and restore the FPU rounding mode, resulting in the
rounding mode remaining as round-to-zero after certain function calls. I do not
know if this also affects MSVC, but better safe than sorry for now.
This improves the transition width, allowing more of the higher frequencies
remain audible. It would be preferrable to have an upper limit of 32 points
instead of 48, to reduce the overall table size and the CPU cost for down-
sampling.
Rather than storing individual pointers to filter, scale delta, phase delta,
and scale phase delta entries, per phase index, the new table layout makes it
trivial to access the per-phase filter and delta entries given the base offset
and coefficient count.
This improves a stereo (front-left + front-right) sound "image" by generating a
front-center channel signal. Done correctly, it helps reduce the comb effects
and phase errors associated with using only two speakers to simulate center
sounds.
Note that it shouldn't be used if the front-center channel is already included
in the positional audio mix (the dialog effect is okay). In general, it may
actually be better to exclude the front-center channel from the positional
audio mix and use this to generate front-center output.
I say "convert" because it takes the lazy way and essentially just embeds the
wrappers into the backend. It's done this way because I lack the means to check
any changes, even syntactically. This also means the device's ExtraData field
is still needed.
However, this does mean all the backends are now using the new API. Code
related to the old interface can now be removed.
This needs to be handled more automatically by the mixer to work correctly.
Otherwise, requiring a property update on resume can put the source into a
playing state with the mixer never playing it, due to not having valid mixing
parameters and the mixing parameters not getting calculated because no updates
are specified by the app (and forcing an update can break deferred updates).
The HF absorption is applied given the source distance, as relative to the
source's immediate environment, with additional absorption being applied given
the room/reverb environment. This does double up the amount of absorption
compared to the dry path, but it can be assumed the initial reflections travel
a longer distance.
This is just for the output limiter right now, but in the future can be used
for the compressor EFX effect. The parameters are also hardcoded, but can be
made configurable after 1.18.
This properly accounts for the room rolloff factor for normal air absorption
(which makes it none by default, like distance attenuation), and uses the
reverb's decay time, decay hf ratio, decay hf limit, and room air absorption
properties to calculate an initial hf decay with the WetGainAuto flag. This
mirrors the behavior of the initial distance decay.
The previous value couldn't actually be expressed as a float and got rounded up
to the next whole number value, leaving the potential for an overrun in the
squared sum.
Though it didn't strictly clash since it was for a different component (global
state vs source property), 0x1213 was used by AL_RESAMPLER_NAME_SOFT. Probably
best to avoid duplicate property values regardless.
A bit of a misnomer now since "Nearest" implies rounding (i.e. when the sample
offset is >= .5, it should pick the next sample being closer in time), but that
adds unnecessary complications.
This is a bit more efficient than calling the normal HRTF mixing function
twice, and helps solve the problem of the values generated from convolution not
being consistent with the new HRIR.
This reduces the output volume when the mixed samples extend outside of -1,+1,
to prevent excessive clipping. It can reduce the volume by -80dB in 50ms, and
increase it by +80dB in 1s (it will not go below -80dB or above 0dB).
Clang does not allow using C11's atomic_load on const _Atomic variables.
Previously it just disabled use of C11 atomics if atomic_load didn't work on a
const _Atomic variable, but I think I'd prefer to have Clang use C11 atomics
for the added features (more explicit memory ordering) even if it means a few
instances of breaking const.
If the requested number of mono and stereo sources exceeds 256, the source
limit will be expanded. Any config file setting overrides this. If the device
is reset to have fewer sources than are currently allocated, excess sources
will remain and be usable as normal, but no more can be generated until enough
are delated to go back below the limit.
This is intended to do conversions for interleaved samples, and supports
changing from one DevFmtType to another as well as resampling. It does not
handle remixing channels.
The mixer is more optimized to use the resampling functions directly. However,
this should prove useful for recording with certain backends that won't do the
conversion themselves.
This should cut down on unnecessary quantization noise (however minor) for 8-
and 16-bit samples. Unfortunately a power-of-2 multiple can't be used as easily
for converting float samples to integer, due to integer types having a non-
power-of-2 maximum amplitude (it'd require more per-sample clamping).
