As I've mentioned before our app uses PTT Framework to record and send audio messages. In one of supported by app mode we are using WebRTC.org library for that purpose. Internally WebRTC.org library uses Voice-Processing I/O Unit (kAudioUnitSubType_VoiceProcessingIO subtype) to retrieve audio from mic. According to https://developer.apple.com/documentation/avfaudio/avaudiosession/mode-swift.struct/voicechat using Voice-Processing I/O Unit leads to implicit enabling .voiceChat AVAudioSession mode (i.e. it looks like it's not possible to use Voice-Processing I/O Unit without .voiceChat mode).
And problem is following: when user starts outgoing PTT, PTT Framework plays audio notification, but in case of enabled .voiceChat mode that sound is playing distorted or not playing at all.
Questions:
- Is it known issue?
- Is there any way to workaround it?
Let me start here:
And problem is following: when user starts outgoing PTT, PTT Framework plays audio notification, but in case of enabled .voiceChat mode that sound is playing distorted or not playing at all.
I don't think the voiceChat mode itself is the issue. The PTT Framework is directly derived from CallKit, particularly in terms of how it handles audio, and CallKit has no issue with this as our CallKit sample specifically uses that mode.
However, what IS a known issue is problems with integrating audio libraries that weren't specifically written with PTT/CallKit in mind:
As I've mentioned before our app uses PTT Framework to record and send audio messages. In one of supported by app mode we are using WebRTC.org library for that purpose. Internally WebRTC.org library uses Voice-Processing I/O Unit (kAudioUnitSubType_VoiceProcessingIO subtype) to retrieve audio from mic.
The big issue here is that most audio libraries do their own session activation and that pattern doesn't work for PTT/CallKit. Depending on exactly what exactly the library does (and when), that can cause exactly the kinds of problems you're describing when the audio session ends up misconfigured in a way that the library isn't expecting. The solution here is basically "don't activate that audio session yourself". The PTT framework should handle all session activation, with the only exception from being the interruption handler. See our CallKit sample for how this should work (again, CallKit and PTT handle audio in the same way).
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware