3 ms·
If putting the thread to sleep would be the problem, simple try_to_lock instead of blocking would be the solution. In practice, it looks like releasing the lock
by oriolid 3y ago
If putting the thread to sleep would be the problem, simple try_to_lock instead of blocking would be the solution. In practice, it looks like releasing the lock and potentially waking up threads that were blocking on it is another problem (https://timur.audio/using-locks-in-real-time-audio-processing-safely https://timur.audio/using-locks-in-real-time-audio-processin...)
For what it's worth, on macOS profiling audio apps shows that the OS itself is using mutexes on audio thread and it doesn't seem to be a problem. The popular JUCE libraries add another set of mutexes.
- gpderetta 3y agotry_lock fails. Then what?
- deleted 3y ago[deleted]
- oriolid 3y agoCiting TFA, > If you’re less lucky, you’ll have to switch your audio effect to bypass mode, or perhaps fade out, or some similar fallback strategy. It’s probably not ideal, but in many cases still better than a glitch.
- dspig 3y agoor if the lock is on some smaller part you might be able to still render the audio but e.g. not update the settings that changed yet, and try again next time.