The heap allocation is aligned to MA_CACHE_LINE_SIZE which is an
optimal alignment for ring buffers.
This also reduces the size of the `ma_device` struct for non-duplex
devices which is the most common setup.
The following functions are removed:
ma_linear_resampler_get_required_input_frame_count()
ma_linear_resampler_get_expected_output_frame_count()
ma_resampler_get_required_input_frame_count()
ma_resampler_get_expected_output_frame_count()
ma_data_converter_get_required_input_frame_count()
ma_data_converter_get_expected_output_frame_count()
These functions were used for calculating the required number of input
frames given an output capacity, and the number of expected number of
output frames given an input frame count. In practice these have proven
to be extremely annoying and finicky to get right. I myself have had
trouble keeping this working consistently as I make changes to the
processing function and I have zero confidence custom resampling
backends will implement this correctly.
If you need this functionality, take a copy of the resampler from
miniaudio 0.11.x and maintain that yourself.
The idea here is to only update the resampler object once at the end.
This improves speeds up the problematic s16 mono upsampling path with
Clang, but that same path with GCC is still slow somehow.
This makes the s16 mono upsampling path slower somehow. This seems to be
the problem code path for some reason. Other paths don't seem to be so
sensitive to seemingly harmless changes.
The idea here is to have a more clearly defined data dependency
separation between the resampler and the filtering state which I'm
hoping might open up more optimization opportunities. The problem with
this theory, is that this commit makes the GCC build slower on the s16
mono upsampling path. It appears to be slightly fast with Clang though.
I tried addressing this, but upon doing so the build was slower. It was
especially bad with Clang where is was 2x slower(!), and just slightly
slower with GCC.
Not sure exactly what's going on here, but I guess the compiler is
hitting some edge case that's prevent efficient optimization. What's
weirder, is the slowness only affects the mono s16 code path. Other
code paths are totally fine.
This makes the resampler a bit more self-contained and allows us to do
some resampler-specific optimizations to the filtering process. It also
reduces the size of the `ma_linear_resampler` struct.
My idea here is to make it easier to for the compiler to SIMD-ify some
of the interpolation code. I have not confirmed that it is actually
being SIMD-ified by the compiler, but it is still significantly faster
in both debug and release builds.
There is a mono specialization here which further improves performance.
I have not yet experimented with a stereo specialization, but if it
works it'll be added in a future commit.
This applies only to the f32 no-LPF code path. Other paths will come
later once I'm done with this round of experiments.
These functions are not reliably implemented by all backends and as such
I'd rather not encourage these use of these. These might be removed in
the future.
David Reid