aboutsummaryrefslogtreecommitdiffstats
path: root/OpenAL32/Include/alBuffer.h
Commit message (Collapse)AuthorAgeFilesLines
* Use a different method for storing and looking up buffersChris Robinson2018-01-271-3/+0
| | | | | | | | | | | | | | | | | 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 rely on alMain.h in alBuffer.hChris Robinson2018-01-261-9/+7
|
* Make some functions static that are only used in one sourceChris Robinson2018-01-261-9/+3
|
* Track the buffer's mapped sectionChris Robinson2018-01-231-0/+2
|
* More cleanup for buffer loadingChris Robinson2018-01-211-8/+6
| | | | | Don't bother with unnecessary and unused converters, and remove some unsupported queries.
* Handle double-precision buffers in the mixerChris Robinson2018-01-211-5/+6
|
* Remove support for (signed) byte and ushort sample storageChris Robinson2018-01-211-2/+0
| | | | Also not used without buffer_samples
* Remove (u)int32 sample storage conversionChris Robinson2018-01-211-2/+0
| | | | Unused without the buffer_samples extension
* Remove the old buffer_samples functionsChris Robinson2018-01-211-17/+17
| | | | | | | 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.
* Add methods to "map" a buffer's storageChris Robinson2018-01-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | 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.
* Store 8-bit sample types directly as unsigned byteChris Robinson2018-01-191-1/+1
|
* Remove unnecessary private AL_SOFT_buffer_samples2 definitionsChris Robinson2018-01-191-4/+4
|
* Make a function static that's only used in one source fileChris Robinson2018-01-171-2/+0
|
* Store mulaw and alaw samples directly in the bufferChris Robinson2018-01-171-0/+2
| | | | | | | 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).
* Remove the (u)byte3 sample formatsChris Robinson2017-03-311-2/+0
| | | | | 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.
* Use ALsizei in more placesChris Robinson2017-01-181-8/+8
|
* Remove use of DECL_CONSTChris Robinson2016-09-061-4/+4
| | | | | No idea if it was really gaining us anything, but removing it fixes a crash I was getting with libs built with Clang.
* Avoid using realloc in a number of placesChris Robinson2016-05-211-0/+1
|
* Hold the buffer map lock while handling the bufferChris Robinson2016-05-101-2/+11
|
* Start AL_SOFT_buffer_samples2 as a replacement for AL_SOFT_buffer_samplesChris Robinson2016-04-251-11/+11
|
* Add preliminary AL_EXT_BFORMAT supportChris Robinson2014-10-311-0/+4
| | | | | Currently missing the AL_ORIENTATION source property. Gain stepping also does not work.
* Make the buffer's pack and unpack properties atomicChris Robinson2014-09-031-2/+2
|
* Standardize some New/Delete methodsChris Robinson2014-06-301-1/+1
|
* Load soundfont samples into an ALbufferChris Robinson2014-06-291-0/+5
| | | | | Also remove ALsoundfont's now-unneeded sample storage functions and struct fields.
* Mark a few more functions as constChris Robinson2014-05-231-4/+4
|
* Add an extension to support MSADPCM buffer formatsChris Robinson2014-03-041-0/+1
|
* Add an extension to alter the block alignment for buffer unpack/pack opsChris Robinson2014-03-041-0/+3
| | | | | | | | | | | | | | | | 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);
* Store the original frame size alignment in the bufferChris Robinson2014-03-031-0/+1
|
* Move some inline methods to their appropriate headersChris Robinson2013-11-041-0/+5
|
* Use C99 inline semanticsChris Robinson2013-11-041-3/+2
|
* Fix effect slot struct declarations so KDevelop doesn't barf on themChris Robinson2013-10-071-2/+1
|
* Use a separate value for the maximum buffer channelsChris Robinson2013-07-231-0/+1
| | | | | | | 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.
* Use C99's inline instead of __inlineChris Robinson2013-05-281-3/+3
|
* Fix up some more header includesChris Robinson2012-09-141-1/+1
|
* Fix comment and rename the buffer's self-idChris Robinson2012-04-191-3/+4
|
* Remove the unnecessary AL_MULAW_SOFT, AL_ALAW_SOFT, and AL_IMA4_SOFT definesChris Robinson2012-01-101-3/+3
|
* Append _SOFT to the AL_SOFT_buffer_samples enumsChris Robinson2012-01-101-20/+20
|
* Use sample frames when handling the buffer lengthChris Robinson2011-10-041-3/+4
|
* Remove the OriginalAlign buffer field, and calculate it as neededChris Robinson2011-10-011-2/+1
|
* Add buffer properties to get the internal format, and the length in bytes, ↵Chris Robinson2011-10-011-0/+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.
* Add support for AL_EXT_ALAWChris Robinson2011-10-011-0/+1
|
* Use arrays instead of large switches to decompose formatsChris Robinson2011-09-181-3/+0
|
* Use a RWLock to protect access to a buffer instead of the device lockChris Robinson2011-09-111-0/+2
|
* Use the reference counting functions for the buffer and auxiliary slot refsChris Robinson2011-08-291-1/+1
|
* Fix a commentChris Robinson2011-05-051-1/+1
|
* Use signed samples for 8-bit storageChris Robinson2011-05-051-1/+1
|
* Add support for packed 24-bit samplesChris Robinson2011-04-261-1/+3
|
* Use the defines for the UserFmt* and Fmt* typesChris Robinson2011-03-161-23/+23
|
* Rename SrcFmt -> UserFmtChris Robinson2010-12-031-38/+38
|
* Let the storable format enum values share the input format enum values where ↵Chris Robinson2010-11-291-10/+10
| | | | they overlap
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-11 09:23:21 +0000