-
Notifications
You must be signed in to change notification settings - Fork 9
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Issue2082: move real-time effect calculation to producer side...
... of the playback RingBuffer. It may be making calls to unknown foreign code in plug-ins. Can we trust unknown code really to follow the constraints of a low-latency thread (such as not allocating memory or locking a mutex or similar)? Rather let's do it in the thread that must maintain high throughput, but can tolerate more variance in processing times of batches of data. Note that the "drop quickly" logic on the consumer side is only about the "micro-fades" that last milliseconds, and smooth the transition to silence when stopping. Whether those few microseconds are now realtime-transformed, where they weren't before -- matters little. Note that our own code does some mutex locking in RealtimeEffectManager::ProcessScope, constructing and destroying it, and in Process(); not held for the duraction of the scope. Some way to avoid this locking needs to be found later. This will cause response of playback to changes of the realtime effect settings to become much more laggy. This will be fixed later. (cherry picked from commit 713ced2; modified for Tenacity) Signed-off-by: Avery King <[email protected]>
- Loading branch information
1 parent
a39c797
commit 365e164
Showing
2 changed files
with
93 additions
and
40 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters