| I 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-... |