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