Disable dynamic SDL loading as well as disable SDL for release builds.
This was only used for audio output which can already use OpenAL
if there are back-ends not natively supported by Blender.
- Remove extern/sdlew/
- Remove the WITH_SDL_DYNLOAD build option.
- Remove `bpy.app.sdl.available`.
Ref !127554
Turns out closing AudioUnit handle could interfere with other software.
It is something Apple is investigating, to see if it is API not used
correctly, or whether there is something to be fixed in the Core Audio.
Until then disable the code which closes audio handles. It rolls back
to the situation when the computer might not be able to sleep properly,
but it is how the previous release was, and overall it is less annoying
than causing an interference.
Once the issue is looked into by Apple we will re-iterate over having
both issues (interference and power management) resolved.
Pull Request: https://projects.blender.org/blender/blender/pulls/124400
The issue was caused by an integer overflow in the `FFMPEGReader::seek`, which
lead to different results depending on an exact compiler version and platform.
The overflow happened in the equation which calculates `m_position`, in its
`packet.pts - st_time` part, which is effectively `int64_t - uint64_t` which is
expected to result in `uint64_t` due to the way how upcasting works in C++.
With the values `packet.pts=0` and `st_time=353600` from the test file the
calculation resulted in a negative value, which then wrapped around due to the
unsigned nature of the type, resulting in very big value on arm64. The value
was wrong, but it did not manifest itself as an error, since the seek code
believed it found the place.
However, when built on x86 platform, the result value was very large negative
value. It is possible that the type upcasting went different, due to the
multiplication with a double value later in the formula. And this large negative
value lead to the seeking code to read the entire file, trying to make it so
the `m_position` is not less than the requested position.
Fortunately, the `AVStream::start_time` is `int64_t`, which leads to a simple
fix which avoids signed/unsigned cast, making the seeking code to properly
calculate `m_position` on both arm64 and x64 platforms, regardless of the
compiler.
Pull Request: https://projects.blender.org/blender/blender/pulls/122149
Use COM smart pointer (`ComPtr`) to simplify memory management in WASAPI driver.
This reduces chances of calling `Release()` when a COM object has not been allocated.
Pull Request: https://projects.blender.org/blender/blender/pulls/121828
After 91eb50ec2f, we would get random crashes/asserts from the pulseaudio library like:
`Assertion 'e->mainloop->n_enabled_defer_events > 0' failed at ../pulseaudio-17.0/src/pulse/mainloop.c:261, function mainloop_defer_enable(). Aborting.`
It seems like we would run into a race condition if we didn't guard the
pulseaudio flush command with the pulseaudio mutex.
This is probably because the pulseaudio thread would try to read the
buffer for a tiny bit even after pausing the playback.
Sadly the only way to reproduce this is to playback any scene (seem to happen more often if A/V sync is on) and spam play/pause.
Note that I could not reproduce this on every computer I tested this on.
But by expanding the main pulseaudio mutex lock, I can't seem to reproduce this anymore.
So I think that is the correct solution.
Pull Request: https://projects.blender.org/blender/blender/pulls/120072
Previously in Audaspace there was choice between linear resampler (okay
for preview, but not great for final mix), or "extremely high quality
preset" for rendering the final mix; with nothing in between. I have just
landed "medium" and "low" resampler quality levels in upstream Audaspace
(see https://github.com/audaspace/audaspace/pull/18 with details and
quality spectograms, also comparison with Audacity resampler).
This PR updates Audaspace to latest upstream, and switches to use the newly
added "medium" quality resampler. There's no audible difference (nor visible
one in spectrograms), as far as I can tell.
Timings, rendering out frames 1000-3000 of Sprite Fright Edit blender
studio data set:
- Windows (Ryzen 5950X, VS2022): 92 -> 73 sec
- Mac (M1 Max, clang 15): 70 -> 62 sec
i.e. using a faster audio resampler makes the _whole render process_ be
10-20% faster (however, this from VSE where it combines already pre-rendered
image strips).
Pull Request: https://projects.blender.org/blender/blender/pulls/116059
The sound equalizer is using the Audaspace FFT Convolver.
The blender part creates an array of descriptions of power per "band"
and orders the creation of Equalizer (ISound) in the Audaspace.
Modifier can be created on sound strips. It lets you define
amplification or attenuation over frequency range from 30Hz to 20 kHz.
The power is limited to -30 db - 30 db. This is done using curve
mapping widget.
Co-authored-by: menda <alguien@aqui.es>
Co-authored-by: Richard Antalik <richardantalik@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/105613
`DeviceManager.h` uses `std::string` without explicitly including
the `<string>` header. While older MSVC implicitly included this
header somewhere, the headers for 17.4+ do not leading to a build
error.
Fix for {T99039}.
The problem was that `AUD_mixdown` and `AUD_mixdown_per_channel` were returning pointers to freed memory.
Two key changes are made:
1. The return value of those functions now simply return a bool as to whether the operation succeeded, instead of an optional error string pointer.
2. The error string buffer is now passed into the function to be filled in case an error occurs. In this way, the onus of memory ownership is unamibiguously on the caller.
Differential Revision: https://developer.blender.org/D15260
When AUDASPACE couldn't find NUMPY, it would disable WITH_PYTHON for
the rest of Blender. Now setting the value globally is only done for
standalone AUDASPACE builds. Now it's possible to build Blender with
AUDASPACE & PYTHON but without NUMPY.
While this isn't an especially important configuration to support,
having Python mysteriously disabled is a hassle to troubleshoot.
NOTE: extern/audaspace/CMakeLists.txt has become out sync with the
original [0], it seems this is being maintained in our repository.
[0]: https://github.com/neXyon/audaspace/blob/master/CMakeLists.txt
In ffmpeg 5.0, several variables were made const to try to prevent bad API usage.
Removed some dead code that wasn't used anymore as well.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D14063
Fixes several notable mistakes and missing information
regarding the API documentation (*.rst).
This will allow API stub generators like bpystubgen or
fake-bpy-module to produce more accurate result.
Differential Revision: https://developer.blender.org/D12639
On the blender side this commit fixes importing video files with audio
and video streams that do not share the same start time and duration.
Differential Revision: https://developer.blender.org/D12353
Refactor and improve waveform drawing.
Drawing now can use line strips to draw waveforms instead of only
triangle strips. This makes us able to properly visualize thin waveforms
as they would not be visible before. We now also draw the RMS value of
the waveform.
The waveform drawing is now also properly aligned to the screen pixels
to avoid flickering when transforming the strip.
Reviewed By: Richard Antalik
Differential Revision: https://developer.blender.org/D11184
The duration and start time for audio strips were not correctly read in
audaspace.
Some video files have a "lead in" section of audio that plays before the
video starts playing back. Before this patch, we would play this lead in
audio at the same time as the video started and thus the audio would not
be in sync anymore.
Now the lead in audio is cut off and the duration should be correctly
calculated with this in mind.
If the audio starts after the video, the audio strip is shifted to
account for this, but it will also lead to cut off audio which might not
be wanted. However we don't have a simple way to solve this at this
point.
Differential Revision: http://developer.blender.org/D11917
