4 ms·
You are totally right. Here's my rough personal guideline: prefer mutexes over lockfree code - unless you can't. For example, you cannot lock a mutex from the a
by spacechild1 4y ago
You are totally right. Here's my rough personal guideline: prefer mutexes over lockfree code - unless you can't. For example, you cannot lock a mutex from the audio callback because it might put the thread to sleep and you would miss your deadline. (For anyone interested in this topic: http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing http://www.rossbencina.com/code/real-time-audio-programming-...)
- gpderetta 4y agoSimilar issues with locking mutexes from signal handlers or from high priority threads (if you want to avoid prio-inversion).
- oriolid 4y agoIf 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 4y agotry_lock fails. Then what?
- deleted 4y ago[deleted]
- oriolid 4y 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 4y 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.