aboutsummaryrefslogtreecommitdiffstats
path: root/Alc/ALu.c
Commit message (Collapse)AuthorAgeFilesLines
* Make ComputeAngleGains use ComputeDirectionalGainsChris Robinson2014-10-021-54/+65
|
* Use helpers to set the gain step valuesChris Robinson2014-10-021-142/+73
|
* Add a cast for MSVCChris Robinson2014-09-301-1/+1
|
* Use an ambisonics-based panning methodChris Robinson2014-09-301-15/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/
* Combine some fields into a structChris Robinson2014-09-101-6/+6
|
* Invert the ChannelOffsets arrayChris Robinson2014-09-101-4/+7
|
* Rename activesource to voiceChris Robinson2014-08-211-132/+132
|
* Use an array of objects for active sources instead of pointersChris Robinson2014-08-211-8/+8
|
* Use a NULL source for inactive activesourcesChris Robinson2014-08-211-12/+12
| | | | Also only access the activesource's source field once per update.
* Update COPYING to the latest ↵François Cami2014-08-181-2/+2
| | | | https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt to fix the FSF' address Fix the FSF' address in the source
* Use atomics for the device and context list headsChris Robinson2014-08-011-2/+2
|
* Make the source's buffer queue head and current queue item atomicChris Robinson2014-07-311-3/+3
|
* Explicitly pass the address of atomics and parameters that can be modifiedChris Robinson2014-07-261-4/+4
|
* Use generic atomics in more placesChris Robinson2014-07-221-2/+2
|
* Add macros for generic atomic functionalityChris Robinson2014-07-221-2/+2
|
* Add a source radius property that determines the directionality of a soundChris Robinson2014-07-111-9/+12
| | | | | | | | | 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.
* Remove unused variablesChris Robinson2014-06-131-4/+0
|
* Get the mixer and resampler functions when neededChris Robinson2014-06-131-65/+0
|
* Combine the direct and send mixersChris Robinson2014-06-131-28/+11
|
* Combine some dry and wet path typesChris Robinson2014-06-131-50/+45
|
* Add SSE2 and SSE4.1 linear resamplersTimothy Arceri2014-06-061-0/+8
| | | | | Currently the only way SSE 4.1 is detected is by using __get_cpuid, i.e. with GCC. Windows' IsProcessorFeaturePresent does not report SSE4.1 capabilities.
* Avoid a loop when updating the source position variablesChris Robinson2014-06-021-4/+8
|
* Don't clear the current and step gain values when updating a sourceChris Robinson2014-05-211-89/+66
|
* Put per-channel filter properties togetherChris Robinson2014-05-191-20/+20
|
* Don't pass the DirectParams to the dry-path mixerChris Robinson2014-05-181-51/+74
|
* Use different parameters for HRTF mixersChris Robinson2014-05-181-6/+11
|
* Apply high-pass source filters as neededChris Robinson2014-05-171-5/+48
|
* Add a flag to specify when the low-pass filter needs to applyChris Robinson2014-05-171-8/+16
|
* Store the filter reference frequency in the sourceChris Robinson2014-05-111-12/+20
|
* Update the source send target gains properlyChris Robinson2014-05-111-4/+4
|
* Use a struct to store the source's direct gain/gainhf propertiesChris Robinson2014-05-111-6/+6
|
* Update the output buffer pointer in the Write_* methodsChris Robinson2014-05-101-15/+11
|
* Add a couple constsChris Robinson2014-05-101-2/+2
|
* Store the current buffer queue item, rather than played buffer countChris Robinson2014-05-101-1/+1
|
* Better pack HRTF mixing propertiesChris Robinson2014-05-031-24/+24
|
* Clamp the current and target gain lower bound to epsilonChris Robinson2014-05-031-10/+10
| | | | | Should give a bit more wiggle room for the gain stepping to get lower than the silence threshold.
* Make HRTF stepping values per-channelChris Robinson2014-04-051-2/+2
|
* Remove the click removal buffers for auxiliary effect slotsChris Robinson2014-03-231-38/+0
|
* Add gain stepping to the send mixersChris Robinson2014-03-231-2/+42
|
* Remove the now-unneeded click removal buffers for the deviceChris Robinson2014-03-231-47/+8
| | | | | | They are still there for auxiliary sends. However, they should go away soon enough too, and then we won't have to mess around with calculating extra "predictive" samples in the mixer.
* Step mixing gains per-sample for non-HRTF mixingChris Robinson2014-03-231-15/+112
| | | | | | | | | | | | | | | | | | | | | | | | This fades the dry mixing gains using a logarithmic curve, which should produce a smoother transition than a linear one. It functions similarly to a linear fade except that step = (target - current) / numsteps; ... gain += step; becomes step = powf(target / current, 1.0f / numsteps); ... gain *= step; where 'target' and 'current' are clamped to a lower bound that is greater than 0 (which makes no sense on a logarithmic scale). Consequently, the non-HRTF direct mixers do not do not feed into the click removal and pending click buffers, as this per-sample fading would do an adequate job of stopping clicks and pops caused by extreme gain changes. These buffers should be removed shortly.
* Move the step counter and moving flag to DirectParamsChris Robinson2014-03-231-6/+15
|
* Store the HrtfState directly in the DirectParamsChris Robinson2014-03-231-8/+7
|
* Add a generic vector interface and use it for the active effect slotsChris Robinson2014-03-211-2/+2
|
* Keep track of the mix countChris Robinson2014-03-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | The purpose of this is to provide a safe way to be able to "swap" resources used by the mixer from other threads without the need to block the mixer, as well as a way to track when mixes have occurred. The idea is two-fold: It provides a way to safely swap resources. If the mixer were to (atomically) get a reference to an object to access it from, another thread would be able allocate and prepare a new object then swap the reference to it with the stored one. The other thread would then be able to wait until (count&1) is clear, indicating the mixer is not running, before safely freeing the old object for the mixer to use the new one. It also provides a way to tell if the mixer has run. With this, a thread would be able to read multiple values, which could be altered by the mixer, without requiring a mixer lock. Comparing the before and after counts for inequality would signify if the mixer has (started to) run, indicating the values may be out of sync and should try getting them again. Of course, it will still need something like a RWLock to ensure another (non-mixer) thread doesn't try to write to the values at the same time. Note that because of the possibility of overflow, the counter is not reliable as an absolute count.
* Use a union to combine HRTF and non-HRTF mixer paramsChris Robinson2014-03-191-29/+29
|
* Select the mixer when setting the mixer-specific parametersChris Robinson2014-03-191-39/+42
|
* Store some source mixing parameters in the active source structChris Robinson2014-03-191-73/+76
|
* Use a separate struct for tracking active sourcesChris Robinson2014-03-181-12/+17
|
* Move HRTF macros and function declarations to a separate headerChris Robinson2014-02-231-0/+1
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 19:05:50 +0000