This renames `gainSmoothTimeInFrames` in `ma_engine_config` to
`spatializationVolumeSmoothTimeInFrames` in order to make it more clear
that it specifically affects spatialization.
This removes `isLooping` from these configs:
* ma_sound_config
* ma_resource_manager_data_source_config
The new way to set the initial looping state for these objects is to
use a flag:
* MA_SOUND_FLAG_LOOPING or
* MA_RESOURCE_MANAGER_DATA_SOURCE_FLAG_LOOPING
The motivation for this change is that it allows the initial looping
state to be set without needing `ma_sound_init_ex()` and
`ma_sound_config`.
This adds the following functions:
* ma_encoding_format_from_path()
* ma_encoding_format_from_path_w()
You can use these to pass into ma_decoder_config to skip over decoding
backends that don't support the given file extension.
With this change, there are now new prioritization rules when deciding
which backend to attempt to load from.
* Backends are iterated in the order they are defined in the config.
* If the encoding format is set to ma_encoding_format_unknown, all
backends will be attempted in regular prioritization order.
* If the encoding format is set to something other than
ma_encoding_format_unknown, that is a specific format is being
requested, only backends that report support for that format or
ma_encoding_format_unknown will attempted.
* File extensions are no longer used as a hint for prioritization.
The encoding format in ma_decoder_config should be used to
accelerate backend selection instead.
This adds the following flags:
* MA_SOUND_FLAG_LOOPING
* MA_RESOURCE_MANAGER_DATA_SOURCE_FLAG_LOOPING
These can be used to initialize sounds and resource managed data
sources to loop by default. This is the recommended way to enable
looping for streams. The `isLooping` config option in
`ma_sound_config` and `ma_resource_manager_data_source_config` has been
deprecated. If you are using those, you should switch to the new flag
or else you'll get compiler errors when upgrading to a future version.
When processing a node, miniaudio will read into a temporary buffer
before mixing input attachments. This commit removes the per-node heap
allocation and replaces it with a per-graph stack. This should result
in less memory usage at larger scales, but at the expense of slightly
more usage at smaller scales.
The size of the stack can be configured via ma_node_graph_config. If
ma_engine is being used, it can be done via ma_engine_config.
Previously, processing a node would involve a temporary buffer
allocated on the stack. Because this was fixed size, it would result in
processing being sub-divided into chunks in order to avoid overflowing
that buffer. This becomes an issue when a node needs to have a known
processing size. An example might be some kind of effect that requires
processing be in powers of two.
With this commit, the `processingSizeInFrames` variable in
`ma_node_graph_config` can be used to make it so processing always
happens in fixed sized chunks. In this situations, it's recommended you
always call `ma_node_graph_read_pcm_frames()` with a frame count of a
multiple of `processingSizeInFrames`.
The allocation strategy used here is not optimal and will be improved
in future commits. It currently allocates a buffer per-node, but since
the data contained within it is transient in nature, it should be
possible to use a global fixed sized stack that supports allocating a
variable amount of space within the stack buffer.
David Reid
RainRat
Chris Genova