audio_device_ = webrtc::AudioDeviceModule::Create(webrtc::AudioDeviceModule::kPlatformDefaultAudio, task_queue_factory_.get());
where task_queue_factory_ is initialized with a call to webrtc::CreateDefaultTaskQueueFactory()
This works fine on most platforms (we use webrtc::AudioDeviceModule::kLinuxPulseAudio for Linux).
On iOS, we're updating from M91 to M113, and in M113 some code in thread.cc has been changed such that the ThreadManager will no longer try to determine what the current thread is if it hasn't been explicitly set. The AudioDeviceIOS class (an instance of which will be created with we create the AudioDeviceModule) wants to cache the current thread in it's "thread_" member variable which is only populated in the AudioDeviceIOS constructor. In M113, when we call webrtc::AudioDeviceModule::Create and, in turn, an AudioDeviceIOS instance is also created, the ThreadManager does not have a current thread yet and so always returns NULL. As a result, the thread_ member variable in AudioDeviceIOS is always NULL. This leads to crashes when trying to post any of the "events" (such as audio route changed, interruption began/ended, etc.) to the thread.
Does anyone know if there's a step we might be missing that causes the ThreadManager to be properly initialized with a "current thread"?
I've also tried using the newer AudioDeviceModuleIOS class by doing the following only on iOS:
audio_device_ = webrtc::CreateAudioDeviceModule(false);
audio_device_->Init();
However, this doesn't solve the problem, the ThreadManager still doesn't have a current thread and the underlying AudioDeviceIOS instance still has NULL for it's thread_ member variable.
Thanks for any insight you may have!
Best,
--RonD