[openal] [WIP] AL_EXT_MSADPCM in OpenAL Soft
Ethan Lee
flibitijibibo at flibitijibibo.com
Wed Mar 5 08:57:58 EST 2014
Looks great to me! It certainly looks a lot nicer than my solution...
But, currently getting an odd segfault in Convert_ALshort_ALmsadpcm,
seems to happen at the Conv_ALshort_ALshort line. Couldn't figure it
out, so I've got a test case over here if anyone wants to look at it:
http://www.flibitijibibo.com/testCaseMSADPCM.tar.bz2
Currently testing this on 64-bit Linux. The test case opens headerless
MSADPCM64 data and sends it to the buffer, playing the result when
successful (should just be a short clicking sound).
-Ethan
On 03/05/2014 03:40 AM, Chris Robinson wrote:
> I've added two extensions to OpenAL Soft in git:
> AL_SOFT_block_alignment and AL_SOFT_MSADPCM.
>
> AL_SOFT_block_alignment adds block alignment properties for unpacking
> (reading from user) and packing (writing to user) buffer data. The
> alignments are specified in sample frames. Samples can only be read or
> written in complete blocks. It also, obviously, affects how ADPCM is
> decoded and encoded. An alignment of 0 means a default is used...
> currently this is 65 for IMA4 (to maintain compatibility with existing
> code), 64 for MSADPCM, and 1 for other PCM formats.
>
> AL_SOFT_MSADPCM adds AL_FORMAT_MONO_MSADPCM_SOFT and
> AL_FORMAT_STEREO_MSADPCM_SOFT buffer formats, as described here:
> http://wiki.multimedia.cx/?title=Microsoft_ADPCM
> Pretty self explanatory. It normally uses a block alignment of 64
> sample frames, but this can obviously be changed with the
> AL_SOFT_block_alignment extension.
>
> The exact behavior of the extensions isn't yet set in stone, and can
> be modified based on any feedback (particularly the default MSADPCM
> block alignment, if it really makes any difference). I can also change
> the "SOFT" to "EXT" if anyone thinks it would be a good idea to, I
> just never feel right about using EXT without some general consensus
> from implementors about an extension.
>
> I haven't yet put in any optimizations, such as avoiding the temp
> buffer when dealing with signed 16-bit buffer data. But please test it
> out, let me know how it works, and feel free to provide feedback. :)
More information about the openal
mailing list