| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Semaphores allow for semi-persistent signals, compared to a condition variable
which requires a mutex for proper detection. A semaphore can be 'post'ed after
writing some data on one thread, and another thread will be able to recognize
it quickly even if the post occured in between checking for data and waiting.
This more correctly fixes a race condition with events since the mixer
shouldn't be using mutexes, and arbitrary wake-ups just to make sure an event
wasn't missed was quite inefficient.
|
|
|
|
|
|
| |
To avoid having unknown user code running in the mixer thread that could
significantly delay the mixed output, a lockless ringbuffer is used for the
mixer to provide events that a secondary thread will pop off and process.
|
| |
|
| |
|
|
|
|
|
| |
Unfortunately does not include the Lookup* functions, which need the full type
declaration to offset the pointer.
|
| |
|
| |
|
|
|
|
| |
And make the ID a simple index into it (1-base, to avoid ID 0).
|
|
|
|
|
| |
This is now similar to buffers, being stored in groups of 64 in a vector with
the ID providing the array indices.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than each buffer being individually allocated with a generated 'thunk'
ID that's used with a uint:ptr map, buffers are allocated in arrays of 64
within a vector. Each group of 64 has an associated 64-bit mask indicating
which are free to use, and the buffer ID is comprised of the two array indices
which directly locate the buffer (no searching, binary or otherwise).
Currently no buffers are actually deallocated after being allocated, though
they are reused. So an app that creates a ton of buffers once, then deletes
them all and uses only a couple from then on, will have a bit of waste, while
an app that's more consistent with the number of used buffers won't be a
problem. This can be improved by removing elements of the containing vector
that contain all-free buffers while there are plenty of other free buffers.
Also, this method can easily be applied to other resources, like sources.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This just implements the event methods insofar as tracked state. No events are
generated/reported yet.
|
| |
|
|
|
|
|
|
| |
Rather than hackily combining bit flags with the format, to increase the number
of potential flags. alBufferData now behaves as if calling alBufferStorageSOFT
with a flags value of 0.
|
|
|
|
| |
And a function to "flush" a mapped buffer
|
|
|
|
|
|
| |
Requires having the same format as the last call to alBufferData. Also only
makes sense when given a NULL data pointer, as otherwise the internal data will
be overwritten anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Requires the MAP_READ_BIT or MAP_WRITE_BIT flags to be OR'd with the format
upon a call to alBufferData, to enable mappable storage for the given access
types. This will fail if the format requires internal conversion and doesn't
resemble the original input data, so the app can be guaranteed the size, type,
and layout of the original data is the same as what's in storage.
Then alMapBufferSOFT may be called with appropriate bit flags to get a readable
and/or writable pointer to the buffer's sample storage. alUnmapBufferSOFT must
be called when access is finished. It is currently invalid to map a buffer that
is attached to a source, or to attach a buffer to a source that is currently
mapped. This restriction may be eased in the future, at least to allow read-
only access while in use (perhaps also to allow writing, if coherency can be
achieved).
Currently the access flags occupy the upper 8 bits of a 32-bit bitfield to
avoid clashing with format enum values, which don't use more than 16 or 17
bits. This means any future formats are limited to 24-bit enum values, and also
means only 8 flags are possible when declaring storage. The alternative would
be to add a new function (alBufferStorage?) with a separate flags parameter.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Seems compilers are now allowing a pointer-to-type-array to implicitly convert
to pointer-to-const-type-array.
|
|
|
|
|
| |
Windows still needs to use MAX_PATH in a couple places, but that macro's
guaranteed there.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
And rename alcRing.c to ringbuffer.c for consistency.
|
|
|
|
| |
Also don't use inheritance with FPUCtl.
|
|
|
|
| |
And rename alcConfig.c to alconfig.c for consistency.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Now FuMa and ACN channel orders are required, as are FuMa, SN3D, and N3D
normalization schemes. An integer query (alcGetIntegerv) is added for the
maximum ambisonic order.
|
|
|
|
|
| |
Also keep all free property update structs together in the context instead of
per-object.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The context state properties are less likely to change compared to the listener
state, and future changes may prefer more infrequent updates to the context
state.
Note that this puts the MetersPerUnit in as a context state, even though it's
handled through the listener functions. Considering the infrequency that it's
updated at (generally set just once for the context's lifetime), it makes more
sense to put it there than with the more frequently updated listener
properties. The aforementioned future changes would also prefer MetersPerUnit
to not be updated unnecessarily.
|