Hi guys,
I was just wondering what happens under the hood when the real time audio thread code is running too slow?
I know that it causes hearable clicks/crackles but what happens with the code that was running on the thread? Will the code be interrupted? If so, what happens for instance with mutexes that are locked when the audio thread code is interrupted?
Hopefully someone can explain further in this subject.
Thanks,
Jelle
It probably depends on the operating system, audio hardware/driver and host application involved.
Just for fun I once tested what happens if I on purpose lock a mutex to stop the audio thread for a long time (like seconds) and that essentially just caused the audio to stop and go silent during the locking. There are no doubt other scenarios possible, including kernel panics and blue screens of death. 
You could probably test the behaviors you are getting by somehow logging things. Maybe your audio callback ends up being called again while the old call is still running or maybe following callbacks are simply skipped. I would at least like to believe that the call isn’t ever just entirely interrupted while it is running…(That would certainly create havoc with RAII things in C++. 
)
In XCode, when I have breakpoints in the audio thread, sometimes all audio (even from other apps like chrome) is stopped… but only sometimes…
On macOS, audio threads are typically run in a separate (the “time constrained”) scheduling band, which has a higher priority than all Posix threads, and which requires the computational requirements/deadline to be specified beforehand in absolute time units. If the OS detects that the code in a time constrained thread constantly misses its deadline (e.g., if a mutex is locked and causes priority inversion), the thread’s priority is temporarily degraded to a low Posix priority, in order to prevent system lockup.
I’m not sure how Windows handles those cases.
