| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Note that it still uses FuMa scalings internally. Coefficients loaded from
config files specify if they're FuMa (in both ordering and scaling) or N3D,
and will get reordered or rescaled as needed.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 7ffb9b3056ab280d5d9408fd023f3cfb370ed103.
It was behaving as appropriate before (orienting left did pan it left for the
listener), I was apparently just misinterpreting the matrix.
|
|
|
|
|
|
|
| |
The rotation erroneously specified the orientation of the source relative to
the sound field, whereas it should be the orientation of the sound field *and*
source relative to the listener. So now when the source is oriented left, the
front of the sound field is to the left of the listener.
|
| |
|
|
|
|
|
|
|
| |
It seems a simple scaling on the coefficients will allow first-order content to
work with second- and third-order coefficients, although obviously not with any
improved locality. That may be something to look into for the future, but this
is good enough for now.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Make installation of headers and libraries optional
|
|/ |
|
|
|
|
|
| |
ALC_FALSE now indicates explicitly no HRTF mixing, while ALC_DONT_CARE_SOFT
is autodetect.
|
|
|
|
|
|
|
|
|
| |
For sources with a non-0 radius:
When distance <= radius, factor = distance/radius*0.5
When distance > radius, factor = 1 - asinf(radius/distance)/PI
Also, avoid using Position after calculating the localized direction and
distance.
|
| |
|
| |
|
|
|
|
|
| |
The backend's capture funcs are already called while under a lock, so multiple
threads shouldn't be able to read from it at once.
|
|
|
|
|
| |
This isn't a real solution, but it should get IAudioClient_IsFormatSupported to
stop failing.
|
| |
|
|
|
|
| |
This works better for VS2015, which adds support for the function.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This basically acts as if the app created a new context with the specified
attributes (causing the device to reset with new parameters), then immediately
delete it. Existing contexts remain undisturbed, except for a temporary pause
while the device output is reconfigured.
|
|
|
|
|
|
|
|
|
| |
DISABLED - Generic disabled status
ENABLED - Generic enabled status
DENIED - Not allowed (user has configured HRTF to be off)
REQUIRED - Forced (user has forced HRTF to be used)
HEADPHONES_DETECTED - Enabled because headphones were detected
UNSUPPORTED_FORMAT - Device format is not compatible with available filters
|
|
|
|
|
| |
This can report the status of HRTF, specifying if it's enabled or not and why
(currently only reports unsupported formats, but this may be extended).
|
|\
| |
| | |
Fix mingw build
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
And limit it to first-order again, since there will likely need to be extra
scalings applied.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method is intended to help development by easily testing the quality of
the B-Format encode and B-Format-to-HRTF decode. When used with HRTF, all
sources are renderer using the virtual B-Format output, rather than just
B-Format sources.
Despite the CPU cost savings (only four channels need to be filtered with HRTF,
while sources all render normally), the spatial acuity offered by the B-Format
output is pretty poor since it's only first-order ambisonics, so "full" HRTF
rendering is definitely preferred.
It's /possible/ for some systems to be edge cases that prefer the CPU cost
savings provided by basic over the sharper localization provided by full, and
you do still get 3D positional cues, but this is unlikely to be an actual use-
case in practice.
|
|
|
|
|
|
| |
It's possible to calculate HRTF coefficients for full third-order ambisonics
now, but it's still not possible to use them here without upmixing first-order
content.
|
| |
|
| |
|
|
|
|
|
| |
A functional no-op (cos(a) == cos(-a), -sin(a) == sin(-a)), but Ambisonics
expects the azimuth angle to go counter-clockwise.
|
|
|
|
|
|
|
|
| |
This adds the ability to directly decode B-Format with HRTF, though only first-
order (WXYZ) for now. Second- and third-order would be easilly doable, however
we'd need to be able to up-mix first-order content (from the BFORMAT2D and
BFORMAT3D buffer formats) since it would be inappropriate to decode lower-order
content with a higher-order decoder.
|
| |
|
| |
|
| |
|
| |
|
| |
|