| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Creative's wrapper driver doesn't seem to handle EFX enums for alGetEnumValue,
let alone return values only for what's supported. The only way to check which
filter and effect types it supports is try to set them and check for errors.
|
|
|
|
|
|
|
| |
The generated files won't play correctly if the player doesn't know they're 3-
and 4-channel UHJ (the third and fourth channels must be ignored, or decoded,
for playback). This is largely just for completion's sake, just in case someone
has a use for it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Using the 20-channel dodecahedron, seems to be good enough to handle 16-channel
third-order ambisonics.
|
| |
|
|
|
|
|
|
|
| |
The extended precision of the encoder's 0.6512*X term was guesswork, with no
real basis for it. Switch back to the original value until something better
actually comes up. Also updates the decoder to account for the change in the
encoder.
|
| |
|
|
|
|
|
| |
The characters won't display properly if the system codepage isn't UTF-8, but
at least it shouldn't cut the line off prematurely.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Classic B-Format uses scaling factors W=1, X=sqrt(2), Y=sqrt(2), and Z=sqrt(2),
which is +3dB louder than FuMa. The base factors are designed assuming classic
scaling, so encoding a 0dBFS FuMa signal without accounting for this would
result in the UHJ signal peaking at about -3dBFS. Similarly, decoding UHJ to
FuMa B-Format would be +3dB louder than intended.
So encoding needs to implicitly boost the signal by +3dB, and decoding needs to
attenuate by -3dB.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For 2-channel UHJ, two decoding equations are provided in the original paper.
The alternative one is most often referenced for 2-channel UHJ decoding, but
the original/general one can also be used by assuming T is fully attenuated
(which the format allows for, as T can be variably attenuated by a factor
between 0 and 1 to deal with an imperfect transmission medium).
Neither method can be perfect for 2-channel UHJ, it's irrevocably lossy to the
original source, but my subjective testing indicates the general equation
produces less audibly errant results.
|
| |
|
| |
|
|
|
|
|
|
|
| |
There are no known file formats intended to support 3- and 4-channel UHJ, but
it is possible to store them in various audio files when a player/decoder is
aware of what it's dealing with. So there's no reason not to have it as an
option.
|
| |
|
|
|
|
|
|
| |
Currently only supports 2-channel UHJ, and the produced .amb files shouldn't be
played as normal B-Format (decoded 2-channel UHJ needs to use different shelf
filters).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This should help avoid destructive phase interference. The occlusion low-pass
filter is still applied in the time domain due to no clear topology (cutoff
frequency, slope, bandwidth, etc).
|
|
|
|
| |
Also allow user-declarable thread count.
|
| |
|
|
|
|
|
| |
This should help improve memory use a bit since the SOFA file can be unloaded
before allocating some temp buffers for onset detection and FFT calculation.
|
|
|
|
|
| |
All fields are used for equalization, but only the farthest field is resampled,
reconstructed, normalized, and written to the mhr.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should produce far better results given it works directly on the frequency
response magnitudes prior to phase reconstruction, as it doesn't deal with a
linear phase filter on a truncated time-domain response (with the result also
getting truncated in both direction).
The in-library on-load HRTF resampler still uses the linear filter due to its
relative performance and simplicity benefits. It's good enough as a backup,
though users with custom HRTFs would benefit from resampling when creating the
mhr (adjusting its window size as appropriate/desired).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenAL-Soft fails to compile on some GCC version:
https://travis-ci.com/github/ArthurSonzogni/smk/jobs/318304162
It has regressed likely after:
https://github.com/kcat/openal-soft/commit/c83609277bed4be4ef40ed306bf2c57fefa19519
va_start is defined in:
- <stdarg.h>
- <cstdarg>
The repository is using it from:
- al/error.cpp
- al/filter.cpp
- alc/alu.cpp
- alc/helpers.cpp
- common/alexcpt.cpp
- utils/makemhr/loaddef.cpp
- utils/openal-info.c
This patch is adding its definition in the files missing it:
- common/alexcpt.cpp
- utils/makemhr/loaddef.cpp
- utils/openal-info.c
Bug: https://travis-ci.com/github/ArthurSonzogni/smk/jobs/318304162
|
| |
|
| |
|