| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves fading between HRIRs as sources pan around. In particular, it
improves the issue with individual coefficients having various rounding errors
in the stepping values, as well as issues with interpolating delay values.
It does this by doing two mixing passes for each source. First using the last
coefficients that fade to silence, and then again using the new coefficients
that fade from silence. When added together, it creates a linear fade from one
to the other. Additionally, the gain is applied separately so the individual
coefficients don't step with rounding errors. Although this does increase CPU
cost since it's doing two mixes per source, each mix is a bit cheaper now since
the stepping is simplified to a single gain value, and the overall quality is
improved.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NFC filters currently only work when rendering to ambisonic buffers, which
includes HQ rendering and ambisonic output. There are two new config options:
'decoder/nfc' (default on) enables or disables use of NFC filters globally, and
'decoder/nfc-ref-delay' (default 0) specifies the reference delay parameter for
NFC-HOA rendering with ambisonic output (a value of 0 disables NFC).
Currently, NFC filters rely on having an appropriate value set for
AL_METERS_PER_UNIT to get the correct scaling. HQ rendering uses the averaged
speaker distances as a control/reference, and currently doesn't correct for
individual speaker distances (if the speakers are all equidistant, this is
fine, otherwise per-speaker correction should be done as well).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends the base ALC_SOFT_loopback extension with support for B-Format.
When ALC_FORMAT_CHANNELS_SOFT is set to ALC_BFORMAT3D_SOFT, then additional
attributes must be specified. ALC_AMBISONIC_LAYOUT_SOFT must be set to
ALC_ACN_SOFT or ALC_FUMA_SOFT for the desired channel layout,
ALC_AMBISONIC_SCALING_SOFT must be set to ALC_N3D_SOFT, ALC_SN3D_SOFT, or
ALC_FUMA_SOFT for the desired channel scaling/normalization scheme, and
ALC_AMBISONIC_ORDER_SOFT must be set to an integer value greater than 0 for the
ambisonic order (maximum allowed is implementation-dependent).
Note that the number of channels required for ALC_BFORMAT3D_SOFT is dependent
on the ambisonic order. The number of channels can be calculated by:
num_channels = (order+1) * (order+1); /* or pow(order+1, 2); */
In addition, a new alcIsAmbisonicFormatSupportedSOFT function allows apps to
determine which layout/scaling/order combinations are supported by the loopback
device. For example,
alcIsAmbisonicFormatSupported(device, ALC_ACN_SOFT, ALC_SN3D_SOFT, 2) will
check if 2nd order AmbiX (ACN layout and SN3D scaling) rendering is supported
for ALC_BFORMAT3D_SOFT output.
|
| |
|
| |
|
|
|
|
|
| |
The voices are still all allocated in one chunk to avoid memory fragmentation.
But they're accessed as an array of pointers since the size isn't static.
|
| |
|
|
|
|
|
|
| |
ALsourceProps' Send[] array is placed at the end of the struct, and given an
indeterminate size. Extra space is allocated at the end of each struct given
the number of auxiliary sends set for the device.
|
| |
|
|
|
|
|
| |
TRACEREFs aren't normally important, and for as often as it happens, the added
function calls are wasteful even if they end up doing nothing.
|
| |
|
|
|
|
|
| |
This keeps the decoder matrices and coefficient mapping together for if it
changes in the future.
|
| |
|
|
|
|
|
|
| |
Unsigned 32-bit offsets actually have some potential overhead on 64-bit targets
for pointer/array accesses due to rules on integer wrapping. No idea how much
impact it has in practice, but it's nice to be correct about it.
|
|
|
|
|
|
| |
This should improve positional quality for relatively low cost. Full HRTF
rendering still only uses first-order since the only use of the dry buffer
there is for first-order content (B-Format buffers, effects).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Designed for apps that either don't change the listener's AL_GAIN, or don't
allow the listener's AL_GAIN to go above 1. This allows the volume to still be
increased further than such apps may allow, if users find it too quiet.
Be aware that increasing this can easily cause clipping. The gain limit
reported by AL_GAIN_LIMIT_SOFT is also affected by this.
|
| |
|
| |
|
|
|
|
|
| |
No idea if it was really gaining us anything, but removing it fixes a crash I
was getting with libs built with Clang.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This appears to be how Creative's Windows drivers handle it, and is necessary
for at least the Windows version of UT2k4 (otherwise it tries to play a source
while suspended, checks and sees it's stopped, then kills it before it's given
a chance to start playing).
Consequently, the internal properties it gets mixed with are determined by what
the source properties are at the time of the play call, and the listener
properties at the time of the suspend call.
This does not change alDeferUpdatesSOFT, which will still hold the play state
change until alProcessUpdatesSOFT.
|
|
|
|
|
| |
This is mostly just reorganizing the effects to call the Construct method which
initializes the ref count.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Last time this attempted to average the HRIRs according to their contribution
to a given B-Format channel as if they were loudspeakers, as well as averaging
the HRIR delays. The latter part resulted in the loss of the ITD (inter-aural
time delay), a key component of HRTF.
This time, the HRIRs are averaged similar to above, except instead of averaging
the delays, they're applied to the resulting coefficients (for example, a delay
of 8 would apply the HRIR starting at the 8th sample of the target HRIR). This
does roughly double the IR length, as the largest delay is about 35 samples
while the filter is normally 32 samples. However, this is still smaller the
original data set IR (which was 256 samples), it also only needs to be applied
to 4 channels for first-order ambisonics, rather than the 8-channel cube. So
it's doing twice as much work per sample, but only working on half the number
of samples.
Additionally, since the resulting HRIRs no longer rely on an extra delay line,
a more efficient HRTF mixing function can be made that doesn't use one. Such a
function can also avoid the per-sample stepping parameters the original uses.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently incomplete, as second- and third-order output will not correctly
handle B-Format input buffers. A standalone up-sampler will be needed, similar
to the high-quality decoder.
Also, output is ACN ordering with SN3D normalization. A config option will
eventually be provided to change this if desired.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It will only be used with a cube channel setup, so there's no need to have one
for every possible output channel.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This helps protect against the device changing unexpectedly from multiple
threads, instead of using the global list/library lock.
|
| |
|