When the listener is looking at exactly the same direction as the world
up vector the 3D math breaks down due to a cross product evaluating to
a zero length vector.
This fixes the following APIs:
* ma_calculate_buffer_size_in_milliseconds_from_frames()
* ma_calculate_buffer_size_in_frames_from_milliseconds()
Public issue https://github.com/mackron/miniaudio/issues/283
The range of the value isn't obvious to any compiler, as it could go for
one iteration or 4 billion iterations. Adding MA_ASSUME in these places
helps the compiler understand the range of possible values, and know how
heavily to vectorize (or not vectorize) these loops.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
This tells the compiler that pFrameOut does not alias to pointers used
within the function, and teaches Clang that the loop is vectorizable.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
These values are constant, but Clang has some trouble noticing that,
especially if the loop body is complex enough. This prevents it from
noticing places where vectorization is possible (and desirable).
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
This macro can be used to tell the compiler's optimization passes static
assumptions which you *know* are true about code behavior.
Use of these can be risky -- if you assume incorrectly, the compiler may
emit code that will not work in circumstances you didn't anticipate.
On the other hand, use of this macro in places where the optimizer is
missing an assumption that would have been safe to make can cause it to
emit more compact/optimal code.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Both GCC and Clang can use this feature, so let's make it more general.
I didn't touch the dr_wav/dr_flac parts using this, since I figure the
amalgamated miniaudio.h header isn't the primary source for those.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
I had a situation where I was doing:
ma_backend backends[] = {
ma_backend_jack,
ma_backend_wasapi,
};
ma_context_init(backends, sizeof(backends)/sizeof(backends[0]),
&contextConfig, &context);
And since JACK was unavailable, it fell back to WASAPI. When this
happened, the WASAPI commandIndex and commandCount variables were
already stomped on by the JACK backend initialization, but the WASAPI
backend assumes they are zero-initialized.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Thread Sanitizer was unhappy about these variables being modified on one
thread and read on another (data race).
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
David Reid
Steven Noonan
morlad (iLeitgeb)