| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also vastly simplify and remove related code.
|
|
|
|
|
|
|
| |
They're inherently protected by the mutex for their respective lists. Should
those mutexes be replaced by rwlocks the individual locks should also be
reinstated, but they're unlikely to be unless a lot of contention starts
happening in the read-only case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Don't bother with unnecessary and unused converters, and remove some
unsupported queries.
|
| |
|
|
|
|
| |
Also not used without buffer_samples
|
|
|
|
| |
Unused without the buffer_samples extension
|
|
|
|
|
|
|
| |
The symbols are still there and exported to retain ABI compatibility, but they
no longer do anything except set an AL_INVALID_OPERATION error. They're also
removed from the function and enum tables, since they're not part of any
supported extension.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
They're now decompressed on the fly in the mixer. This is not a significant
performance issue given that it only needs a 512-byte lookup table, and the
buffer stores half as much data (it may actually be faster, requiring less
overall memory).
|
|
|
|
|
| |
They're not accessible since the removal of the buffer_samples extension, and
were kind of clunky to work with as 24-bit packed values.
|
| |
|
|
|
|
|
| |
No idea if it was really gaining us anything, but removing it fixes a crash I
was getting with libs built with Clang.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Currently missing the AL_ORIENTATION source property. Gain stepping also does
not work.
|
| |
|
| |
|
|
|
|
|
| |
Also remove ALsoundfont's now-unneeded sample storage functions and struct
fields.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for unpacking (reading, e.g. alBufferData) and packing (writing, e.g.
alGetBufferSamplesSOFT) operations. The alignments are specified in sample
frames, with 0 meaning the default (65 for IMA4, 1 otherwise). IMA4 alignment
must be a multiple of 8, plus 1 (e.g. alignment = n*8 + 1), otherwise an error
will occur during (un)packing. Chenging the block alignment does not affect
already-loaded sample data, only future unpack/pack operations... so for
example, this is perfectly valid:
// Load mono IMA4 data with a block alignment of 1024 bytes, or 2041 sample
// frames.
alBufferi(buffer, AL_UNPACK_BLOCK_ALIGNMENT_SOFT, 2041);
alBufferData(buffer, AL_FORMAT_MONO_IMA4, data, data_len, srate);
alBufferi(buffer, AL_UNPACK_BLOCK_ALIGNMENT_SOFT, 0);
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Unlike the device, input buffers are accessed based on channel numbers
instead of enums. This means the maximum number of channels they hold
depends on the number of channels any one format can have, rather than
the total number of recognized channels. Currently, this is 8 for 7.1.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
samples, and seconds
The provided buffer lengths correspond to the source offsets, in that the byte
length specifies the end of the byte offset (ie, when the buffer is used for a
static source, the offset will range between 0 (inclusive) and the byte length
(exclusive)). Although an application could use the AL_SIZE, AL_CHANNELS,
AL_BITS, and AL_FREQUENCY properties to find the length in samples and seconds,
the byte length cannot be reliably calculated this way.
|