* ThreadableJob: Move from AtomicInt to std::atomic
This is the first in a series of commits that migrates away from
AtomicInt towards the C++11 standard library types.
This would allow the removal of AtomicInt and related Qt
version-specific code.
While we're at it, also make ProcessingState an `enum class` so that
it's not implicitly convertible to integers.
* LocklessAllocator: Switch from AtomicInt to std::atomic_int
If it looks like some assignments around the Compare & Swap loops went
missing, it's because compare_exchange_weak() updates the first argument
to the current value when it fails (i.e., returns false).
* BufferManager: Remove extra AtomicInt include
* MixerWorkerThread: AtomicInt to std::atomic_int
* NotePlayHandle: AtomicInt to std::atomic_int
* Remove AtomicInt.h
* Move from QAtomicPointer to std::atomic<T*>
This removes some #ifdef trickery that was being used to get
load-acquire and store-release from Qt5 and "plain" (presumably
sequentially-consistent) loads and stores from Qt4.
This prevents a race condition with Qt5. A foreach loop makes a copy of its
Qt container, increasing the reference count to the container's internal
data. Qt5 often asserts isDetached(), which requires the reference count to
be <= 1. This assertion fails when the foreach loop increases the reference
count at exactly the wrong moment. Using a range-based for loop prevents an
unnecessary copy from being made and ensures this race condition isn't
triggered.
Well, this commit got a bit out of hand, what with 26 files changed. Oh well.
Basically, we're using the buffermanager to dispense temporary buffers for playhandles and audioports to use.
This allows us to change the way playhandles work. Earlier, playhandles of the same track were waiting in line
to push their output to the audioport. This was of course inefficient, so now they just register themselves to the port,
then the port handles mixing the buffers.
Caveat: this is still a work in progress, the vol/pan knobs on instruments are temporarily non-functional - will be fixed in
the next commit, but I have to get some sleep now.
Issue: Currently, we use threads to process all PlayHandles, so there's no guarantee of the order they are processed in. This causes timing inaccuracy and jitter: notes of instruments that use both NPH's and IPH's can get randomly delayed by one entire period.
The issue is solved thusly:
- When processing an IPH, we check if the instrument is midi-based. If yes, we just process it normally (no NPH's to worry about).
- If it's not, then it also uses NPH's, so we'll have the IPH wait until all NPH's belonging to same instrument have been processed. There's some similar code in the new FX mixer, I pretty much just copied how we do it there.
Next big coding style update - this time all PlayHandle classes are
affected. Functions like done() and released() were renamed to
isFinished() and isReleased().
In order to provide smooth muting functionality (i.e. immediate proper
sound when unmuting) always render audio buffers for MIDI-based
instruments. This is more important than potentially reduced CPU usage
while muted.
Closes#69.
While regular instruments were excluded from processing when muted
this did not happen for InstrumentPlayHandle-based instruments. Muting
for exampling tracks with VSTi's inside did not decrease CPU usage.
Checking whether related InstrumentTrack is muted before calling
Instrument::play() fixes this issue.
Closes#2857426.
(cherry picked from commit 6940d19969)
