Create a fast and reusable sound engine

[Dawoodoz]

Fast
SIMD vectorized playback of sounds without interpolation. Changing volume should be optional to save performance. Having the same volume on all channels should only multiply once.

Efficient
The backends should stop requesting samples when there are no sounds to play, so that it can be used for basic click sounds in an otherwise silent application. Future operating-systems might have a significant delay for initializing playback, but closing and restarting when needed would be the simplest solution to re-implement, making sure that all implementations support this feature just by cleaning up resources. One can also make a setting to run the sound engine without interrupting on silence, to get lower latency for applications that run sounds almost constantly.

Standardizing
The sound engine should try to standardize basic types and methods for storing and converting sounds, which can be in a separate sound core API, not listed in the framework subset, without adding dependencies to sound backends when only used to process sound for conversion tools. This allow sound encoders and decoders for different file formats to be reused across different sound engines. First define how to load into a lossless integer sound buffer, then use standard conversion functions to convert between different sound formats.

Non-imposing
Custom sound engines should be free not to use the SDK's example sound engine, add their own sound formats for import or in-memory compression, have their own pipeline design for distorting effects, and do their own sound mixing for different usecases and optimizations.

[Dawoodoz]

The new F32xF SIMD vector will allow sound engines to take advantage of 256-bit SIMD from AVX when present and fall back on 128-bit SIMD when not available. Then older low-end laptops will have fast sound to afford many sounds playing at the same time.

[Dawoodoz]

Having 3D surround sound might require fetching the speaker configuration from the system to automatically use surround sound when available. More system dependencies should be optional to integrate, by defaulting on stereo if featching a speaker setup is not implemented. A list with some standard speaker placements should allow getting surround sound even if the system won't give the default setup or if the user can't find the settings.

Just mono and stereo is probably fine for a first version, as long as 3D sounds can be added later without breaking the design. Maybe one API for sound buffers, a simple API for 2D and another for 3D with listeners and effects.