Fixes#135897 by introducing a mixing thread to coreaudio, making the callback lock free. At the same time these changes unify all devices that use a mixing thread (now that's jack, pulse, pipewire and coreaudio).
Pull Request: https://projects.blender.org/blender/blender/pulls/136711
Removes the playback handle from the synchronizer API and integrates it
into the device, removing the ISynchronizer interface completely.
This has been discussed in more detail in #126047 and its main purpose is to unify the handling of synchronizer events, especially seek which needed different logic for jack vs other backends.
OpenAL now needs a silence playback handle for synchronization but all
other backends are pretty straightforward just counting the mixed
samples in the SoftwareDevice with some specializations for specific
backends that had their own synchronizers before.
Note: CoreAudio changes are untested as I don't have a Mac.
Pull Request: https://projects.blender.org/blender/blender/pulls/133191
There's a "Render -> Render Audio" operator that pretty much calls into Audaspace functionality directly. This PR adds two new options in there, that boThere's a "Render -> Render Audio" operator that pretty much calls
into Audaspace functionality directly. This PR adds two new options in
there, that both feel like an oversight:
- There's an option for AAC container, when someone wants to render
into .aac file. Previously you could render AAC audio, but only in
MKV (Matroska) container. This is a user request #131980.
- When using MKV (Matroska) or Ogg container, it did not list Opus as
an audio codec that can be used. This felt like an oversight; both
the rest of Blender and Audaspace can handle that, jus the option
was not spelled out in the RNA enums.
Pull Request: https://projects.blender.org/blender/blender/pulls/132877th feel like an oversight:
- There's an option for AAC container, when someone wants to render into `.aac` file. Previously you _could_ render AAC audio, but only in MKV (Matroska) container. This is a user request #131980.
- When using MKV (Matroska) or Ogg container, it did not list Opus as an audio codec that can be used. This felt like an oversight; both the rest of Blender and Audaspace can handle that, jus the option was not spelled out in the RNA enums. Note however that without fix in #132872 the Matroska container continues to be useless in that it produces wrong result.
Upstream Audaspace PR for the 2nd point: https://github.com/neXyon/audaspace/pull/47 (was just merged!)
Pull Request: https://projects.blender.org/blender/blender/pulls/132877
Matroska container really really wants to internally keep on using
milliseconds as a time base. Even if at initialization time both the
m_stream and m_codecCtx are set to use {1, sample_rate} timebase,
later during the avformat_write_header call the audio stream gets set
to {1, 1000}.
Doing av_packet_rescale_ts for each packet after receiving it but
before writing it seems to do all the correct work. This is what is
being done inside Blender movie_write_audio.cc, and in official ffmpeg
mux.c example.
Pull Request: https://projects.blender.org/blender/blender/pulls/132872
While I implemented pipewire support I forgot that some of the functions I use is not available in older pipewire versions.
This adds proper library version sanity checks for pipewire.
Pull Request: https://projects.blender.org/blender/blender/pulls/131610
CMake 3.31 has begun to emit the following warning:
```
CMake Deprecation Warning at extern/audaspace/CMakeLists.txt:17
Compatibility with CMake < 3.10 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
```
The main blender CMakeLists has a `cmake_minimum_required(VERSION 3.10)`
already so it's likely the one in audaspace isn't needed. given it is there
however and i'm not entirely sure about the history why it is there i bumped
it to `3.10` so it aligns with the main blender one.
Pull Request: https://projects.blender.org/blender/blender/pulls/130566
This is being added straight to 4.2, prior to the `make license` command
which will use this to generate a more complete license file.
Licenses information and ambiguities worked with Dalai Felinto.
Part of !129018.
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
