aboutsummaryrefslogtreecommitdiffstats
path: root/OpenAL32/Include/alBuffer.h
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Make the decompose functions return false when given an unhandled formatChris Robinson2010-11-291-3/+3
|
* Reorder some parameters for consistencyChris Robinson2010-11-291-5/+5
|
* Store the decomposed source format in the bufferChris Robinson2010-11-291-3/+4
|
* Add IMA4 as a source data typeChris Robinson2010-11-291-0/+1
|
* Add support for (unsigned) int input formatsChris Robinson2010-11-291-0/+2
|
* Reorder and rename parameters for the format decomposition functionsChris Robinson2010-11-291-4/+4
|
* Uninline a couple more functionsChris Robinson2010-11-291-54/+4
|
* Store double formats as floatChris Robinson2010-11-281-2/+0
| | | | | The mixer will cut it down to float anyway, so it's unnecessary and needlessly creates more mixer functions
* Rename some stuff for consistencyChris Robinson2010-11-281-8/+8
|
* Don't store the internal format in the bufferChris Robinson2010-11-281-7/+70
| | | | The type and channel config are good enough
* Support rear formats directly in the mixerChris Robinson2010-11-271-0/+1
|
* Support muLaw with LoadDataChris Robinson2010-11-271-0/+1
|
* Don't inline the decompose functionChris Robinson2010-11-271-87/+1
|
* Decompose input buffer formats and use it when converting uncompressed dataChris Robinson2010-11-271-0/+23
|
* Rename a functionChris Robinson2010-11-271-2/+2
|
* Support 64-bit double buffers directlyChris Robinson2010-11-271-0/+1
|
* Use enums when selecting the mixerChris Robinson2010-11-261-0/+106
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 16:31:58 +0000