openal-soft icon indicating copy to clipboard operation
openal-soft copied to clipboard

Native ADPCM buffers

Open ringoz opened this issue 4 years ago • 4 comments

While trying to optimize memory consumption, I've discovered IMA4/MSADPCM are converted to INT16 internally. Let's get rid of this conversion.

ringoz avatar Oct 31 '20 11:10 ringoz

It won't be easy. ADPCM is a block-based format, where you need whole blocks which decode to a set number of samples, but the mixer works with sample offsets and counts that don't have to align with those blocks. The mixer would need to decode each block as needed, and track the current block and offset within it (as well as handle loops and offset changes, where it can start reading samples in the middle of a new block).

kcat avatar Nov 03 '20 10:11 kcat

Yeah, but the challenge is worthy. The format is still in demand on mobile, all commercial sound engines provide their optimized ADPCM implementations.

At first, I was skeptical about the quality. Then encoded my samples with https://github.com/dbry/adpcm-xq and wow - very good results!

ringoz avatar Nov 03 '20 13:11 ringoz

Besides, the refactoring involved may help in solving other things. Like procedural buffers etc.

ringoz avatar Nov 03 '20 14:11 ringoz

Good news, the latest commits (ending with commit fcfe0277a4e13445727ae5bc764fb5276d1713c5, which fixed a minor offset bug) now handle ADPCM buffers natively, decoding them on-the-fly in the mixer without converting to and storing signed 16-bit samples. The decoding process isn't likely the most optimal, so you should probably be careful about playing too many such buffers at once, but the capability is there.

The short amount of testing I've done shows it working fine, but if you have more thorough use-cases, checking it to make sure it works would be a good idea.

kcat avatar Feb 15 '23 07:02 kcat