[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