The issue with this one was that the brute-force path was seeking back
to the start of the file rather than seeking to the start of the audio
data within the file.
The issue with this one is that it was possible for the asynchronous
loading process to override settings that were explicitly set via
ma_data_source_set_*(). The fix for this is to only set these on the
asynchronous side if the values in the resource manager's data source
config is not equal to defaults.
The issue here is that the code is trying to maintain the absolute
position of the loop point. The problem with this is that the absolute
position of the loop points could fall outside the new range which
would then result in no audio being read.
This becomes an issue because it would effect data sources even when
the loop point was never actually explicitly set. From these users
perspective, changing the range completely breaks their audio.
The new system simply resets the loop points. This works for users who
are using the default loop points (the majority of cases). For those
who are explicitly setting a loop point, they simply need to reset
their loop points after changing the range. This is not really an
issue, because loop points are relative to the range, which means a
change in the range would most likely warrant a change in the loop
point anyway.
Updating the noise type should not be supported. An oversight on my
part. Users should reinitialize a fresh `ma_noise` object instead.
This change simply returns an error and triggers an assert in debug
mode.
Public issue: https://github.com/mackron/miniaudio/issues/585
By using the gainer to apply the master volume, we can essentially get
master volume control for free by premultiplying the per-channel
volumes by the master volume before processing.
If you were previously using this, it will no longer have any effect.
SSE2 and NEON will be used if supported, but can be disabled with
`MA_NO_SSE2` and `MA_NO_NEON`.