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
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
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
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
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
- Changing API for time values from float to double for better precision.
- Fixing minor mistakes in the documentation.
- Fixing minor unnecessary large memory allocation.
Due to some floating point errors the last frame of a VSE audio strip can
cause integer overflow and crash Blender. This overflow was caused by a
cast from `int64_t` to `int` without prior check. The crash is fixed by
keeping the variable as `int64_t` for as long as possible.
