This is created to address the issue of USB headsets being removed or Bluetooth headsets with bad connections causing the viewer to lock up.
First Part: WebRTC
WebRTC now has an added inline atomic bool used to track when the worker thread is accessing the audio hardware. If the coroutine that is always running detects 10 consecutive true flag values, it will set WebRTC to exit and exit itself.
This coroutine was what was locking up the viewer as it spammed the mMainQueue with messages every update, but the worker thread was locked up and unable to receive the messages. Once the queue reached 1024 messages, it would lock up.
Underlying issue is the Windows Core Audio driver system crashes if too many threads have requests to get audio updates upon hardware changes. And with a USB headset having 2 devices in 1, it multiples the updates by 2x. The WebRTC audio system itself locks a mutex as it calls the core audio system to get set the input, but if it is already being processed by another thread, it then gets an exception to try again. The audio driver is not handling the message and crashes and does not return leaving the WebRTC worker thread locked.
0cdae450d8