If the state miniaudio side of the device does not match the actual
state of the backend side of it, such as when the device is stopped but
the backend doesn't post a notification, attempting to stop the device
might result in a deadlock.
This is a just a quick workaround hack for the moment while a more
robust solution is figured out.
https://github.com/mackron/miniaudio/issues/717
The SSE2 code paths for mono expansion introduced in Version 0.11.15
mixed up the parameters of `_mm_shuffle_ps()`, which in turn caused
adjacent PCM frames to be swapped in the channel-expanded output.
This unifies, as much as possible, the ScriptProcessorNode path with
the AudioWorklets path to avoid some code duplication, and to also make
the two paths more similar to each other to ease in maintenance.
This adds the following APIs:
* ma_sound_stop_with_fade_in_pcm_frames()
* ma_sound_stop_with_fade_in_milliseconds()
* ma_sound_set_stop_time_with_fade_in_pcm_frames()
* ma_sound_set_stop_time_with_fade_in_milliseconds()
These functions will overwrite any existing fades. For the
set_stop_time variants, you specify the time that the sound will be put
into it's stopped state. The fade will start at stopTime - fadeLength.
If the fade length is greater than the stop time, the fade length will
be clamped.
Public issue https://github.com/mackron/miniaudio/issues/669
This change makes use of the onInitFile, onInitFileW and onInitMemory
backend callbacks which enables decoding backends to have optimized
implementations for reading from a file or a block of memory without
having to go through an abstraction layer on the miniaudio side.
Public issue https://github.com/mackron/miniaudio/issues/696
This is optional and is fired at the end of each call to
ma_engine_read_process_pcm_frames(). The callback will be passed the
processed audio data so they can do their own processing such as
outputting to a file or whatnot.
The callback is configured via the engine config.
David Reid
my1e5
Oldes
nmlgc
Taiko2k
Jay Baird