| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, 5.1 surround sound is supposed to use the "side" channels, not the
back channels, and we've been wrong this whole time. That means the "5.1 Side"
is actually the correct 5.1 setup, and using the back channels is anomalous.
Additionally, this means the 5.1 buffer format should also use the the side
channels instead of the back channels.
A final note: the 5.1 mixing coefficients are changed so both use the original
5.1 surround sound set (with the surround channels at +/-110 degrees). So the
only difference now between 5.1 "side" and 5.1 "back" is the channel labels.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Currently missing the AL_ORIENTATION source property. Gain stepping also does
not work.
|
|
|
|
|
|
|
|
|
|
| |
This behavior better matches Creative's hardware drivers and Rapture3D's OpenAL
driver. A compatibility environment variable is provided to restore the old
no-op behavior for any app that behaves badly from this change (set
__ALSOFT_SUSPEND_CONTEXT to "ignore").
If too many apps have a problem with this, the default behavior may need to be
changed to ignore, with the env var providing an option to defer/batch instead.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For mono sources, third-order ambisonics is utilized to generate panning gains.
The general idea is that a panned mono sound can be encoded into b-format
ambisonics as:
w[i] = sample[i] * 0.7071;
x[i] = sample[i] * dir[0];
y[i] = sample[i] * dir[1];
...
and subsequently rendered using:
output[chan][i] = w[i] * w_coeffs[chan] +
x[i] * x_coeffs[chan] +
y[i] * y_coeffs[chan] +
...;
By reordering the math, channel gains can be generated by doing:
gain[chan] = 0.7071 * w_coeffs[chan] +
dir[0] * x_coeffs[chan] +
dir[1] * y_coeffs[chan] +
...;
which then get applied as normal:
output[chan][i] = sample[i] * gain[chan];
One of the reasons to use ambisonics for panning is that it provides arguably
better reproduction for sounds emanating from between two speakers. As well,
this makes it easier to pan in all 3 dimensions, with for instance a "3D7.1" or
8-channel cube speaker configuration by simply providing the necessary
coefficients (this will need some work since some methods still use angle-based
panpot, particularly multi-channel sources).
Unfortunately, the math to reliably generate the coefficients for a given
speaker configuration is too costly to do at run-time. They have to be pre-
generated based on a pre-specified speaker arangement, which means the config
options for tweaking speaker angles are no longer supportable. Eventually I
hope to provide config options for custom coefficients, which can either be
generated and written in manually, or via alsoft-config from user-specified
speaker positions.
The current default set of coefficients were generated using the MATLAB scripts
(compatible with GNU Octave) from the excellent Ambisonic Decoder Toolbox, at
https://bitbucket.org/ambidecodertoolbox/adt/
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also only access the activesource's source field once per update.
|
|
|
|
| |
https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt to fix the FSF' address Fix the FSF' address in the source
|
| |
|
|
|
|
|
|
|
|
| |
There's apparently some issues with it causing noise or killing the output. It
might be due to the per-sample changes being too harsh for the filter to keep
up with, but it's not something I can take care of in time for release.
This commit should be reverted after release when work on fixing it can resume.
|
| |
|
| |
|
|
|
|
| |
And remove an unnecessary void cast
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
If the source is stopped, changes its buffer, then played again quickly, the
source will never be removed from the active source list causing the update
method to remain as it was. If the buffer was changed between mono and multi-
channel, this causes it to use the wrong method.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This allows multiple soundfont files to be "patched" together to create a
single soundfont. For instance a GM soundfont with a separate soundfont for
GS-only additions.
|
|
|
|
|
|
|
|
|
| |
At 0 distance from the listener, the sound is omni-directional. As the source
and listener become 'radius' units apart, the sound becomes more directional.
With HRTF, an omni-directional sound is handled using 0-delay, pass-through
filter coefficients, which is blended with the real delay and coefficients as
needed to become more directional.
|
| |
|
| |
|
| |
|
| |
|