3 ms·
> dogmatically following this advice might be overkill It depends on your appetite for risk and the cost of failure. A big part of the problem is that general
by RossBencina 2y ago
> dogmatically following this advice might be overkill
It depends on your appetite for risk and the cost of failure.
A big part of the problem is that general purpose computing systems (operating systems and hardware) are not engineered as real-time systems and there are rarely vendor guarantees with respect to real-time behavior. Under such circumstances, my position is that you need to code defensively. For example, if your operating system memory allocator does not guarantee a worst-case bound on execution time, do not use it in a real-time context.
- ssfrr 2y agoI don't mean to devalue the advice here. I think it's spot on, and I unreservedly recommend this article to folks who want to learn about writing reliable audio software. I think in essence I'm repeating the comments of Justin from Cockos, which you summarize [1]: > It is basically saying that you can reduce the risk of priority inversion to the point where the probability is too low to worry about. In that comment you also say: > 100% certainty can’t be guaranteed without a hard real-time OS. However 5ms is now considered a relatively high latency setting in pro/prosumer audio circles Which I interpret as acknowledging that we're already forced into the regime of establishing an acceptable level of risk. My point is that I would love to see more data on the actual latency distributions we can expect, so that we can make more informed risk assessments. For example, I know that not all `std::atomic` operations are lock-free, but when the critical section is so small, is it really a problem in practice? I want histograms! [1]: http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing#comment-87 http://www.rossbencina.com/code/real-time-audio-programming-...