| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Not all IDE parsers necessarily choke on restrict, and even those that do can
probably have their own configuration to define macros that can hide the
parsing errors caused by it.
|
|
|
|
|
| |
On Windows it'll look for alsoft.ini, and elsewhere is alsoft.conf. This
applies after the user-local settings and before ALSOFT_CONF.
|
|
|
|
|
| |
It will only be used with a cube channel setup, so there's no need to have one
for every possible output channel.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
perf shows a 5% drop in relative execution time on the alffplay example with an
audio-only file (20% to 15%). Kinda figured the optimizer would handle it
better, but I guess not.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
i.e. without the latency
|
|
|
|
|
| |
The only mixer locking involved is with the backend, as determined by it's
ability to get the device clock and latency atomically.
|
|
|
|
|
|
| |
This will also allow backends to better synchronize the tracked clock time with
the device output latency, without necessarily needing to lock if the backend
API can allow for it.
|
| |
|
|
|
|
|
| |
This helps protect against the device changing unexpectedly from multiple
threads, instead of using the global list/library lock.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Avoids the backend device lock, instead using the list lock to prevent the
device from changing while being queried, and adds some missing locks.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Since the wet path is essentially the room response to a sound, the direction
of the sound to the listener doesn't change the amount of energy the room
receives. Instead, the surface area defined by the cones dictate the volume the
room gets for the sound.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
In case allocation fails, we don't have to worry about the playing status of
the backend.
|
|
|
|
|
|
|
| |
If an unapplied update was superceded, it would be placed in the freelist with
its effect state object intact. This would cause another update with the same
effect state object to be placed into the freelist as well, or worse, cause it
to get deleted while in use when the container had its effect state cleared.
|
|
|
|
|
| |
This fixes a potential missed state change if an update with a new state got
replaced with one that doesn't.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This necessitates a change in how source updates are handled. Rather than just
being able to update sources when a dependent object state is changed (e.g. a
listener gain change), now all source updates must be proactively provided.
Consequently, apps that do not utilize any deferring (AL_SOFT_defer_updates or
alcSuspendContext/alcProcessContext) may utilize more CPU since it'll be
filling out more update containers for the mixer thread to use.
The upside is that there's less blocking between the app's calling thread and
the mixer thread, particularly for vectors and other multi-value properties
(filters and sends). Deferring behavior when used is also improved, since
updates that shouldn't be applied yet are simply not provided. And when they
are provided, the mixer doesn't have to ignore them, meaning the actual
deferring of a context doesn't have to synchrnously force an update -- the
process call will send any pending updates, which the mixer will apply even if
another deferral occurs before the mixer runs, because it'll still be there
waiting on the next mixer invocation.
There is one slight bug introduced by this commit. When a listener change is
made, or changes to multiple sources while updates are being deferred, it is
possible for the mixer to run while the sources are prepping their updates,
causing some of the source updates to be seen before the other. This will be
fixed in short order.
|
|\
| |
| | |
alsoft-config: Raise source limit to 4096
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to the listener, separate containers are provided atomically for the
mixer thread to apply updates without needing to block, and a free-list is used
to reuse container objects.
A couple things to note. First, the lock is still used when the effect state's
deviceUpdate method is called to prevent asynchronous calls to reset the device
from interfering. This can be fixed by using the list lock in ALc.c instead.
Secondly, old effect states aren't immediately deleted when the effect type
changes (the actual type, not just its properties). This is because the mixer
thread is intended to be real-time safe, and so can't be freeing anything. They
are cleared away when updates reuse the container they were kept in, and they
don't incur any extra processing cost, but there may be cases where the memory
is kept around until the effect slot is deleted.
|