@DTS Engineer Thank you for that long explanation. It's really useful. Expanding on something I said earlier, my longstanding (originally based on experience with CallKit and now applied to the PTT framework) view is that VOIP/PTT apps can't really be built on our high level audio APIs (like AVAudioRecorder). It has meaning. But what framework you would recommend for audio recording with PTT Framework? As I said before I see issue with Voice-Processing I/O Unit and it's pretty low level I believe. Of course it can be related to wrong Audio Session management you told above, I'll check it, but anyway, what you would recommend for that task?

@DTS Engineer I've repoted bug FB16716531 The direct issue in your code is the "setVoiceProcessingEnabled(false)". I'm not sure what you're intention here was, but there's obviously a conflict between setting ".voiceChat" and then disabling voice processing. With "setVoiceProcessingEnabled(true)", the record warning tone always played. Actually production app doesn't use AVAudioEngine at all. I've used it just to create minimal possible repro case. But with AVAudioRecorder I see the same issue. I've added enabling AVAudioRecorder use to demo app, please check. Also app has very similar issue with Voice-Processing I/O Unit but I didn't add it to demo since it will need some additional effort and overcomplicate demo app. As a broader comment, I'm concerned about timing issues around how you're using "Task" to manipulate the audio system. I understand your point, but as usual problem here is with multithreading. PTT Framework uses some worker thread to send notifications to PTChannelManagerDelegate, so It required to have some threads synchronisation there. Obvious options are: Task DispatchQueue.sync() Mutex DispatchSemaphore and problem is all except 1. will block calling thread. And I don't think it's good. Also, It's not possible just use hardcoded AVAudioSession options, since they can be different when it uses AVAudioRecorder or Voice-Processing I/O Unit (WebRTC).

@DTS Engineer I've implemented minimal app reproducing issue. Please look https://github.com/RSATom/PTTPlayground I've tested it on iPhone 14 Pro and was able to reproduce issue with 100% tries.

@DTS Engineer yes, I know about this restriction. And I've disabled AudioSession activation inside WebRTC.org library (but I'll check one more time to be sure 100%) and still see issue. Also as I mentioned before, in our code we have path using AVAudioRecorder for the same purpose, and adding .voiceChat mode there gives identical result. And everything is fine without it. Also, to avoid possible side effects from third part libraries with hard to understand side effects I've did small experiment with AVAudioEngine: let engine = AVAudioEngine() defer { engine.stop() } let inputNode = engine.inputNode // just to create node accessing mic try inputNode.setVoiceProcessingEnabled(false) // if remove this, PTT start sonification will be distorted!!! try engine.start() try await Task.sleep(for: .milliseconds(150)) and as mentioned in comment, if remove try inputNode.setVoiceProcessingEnabled(false) PTT start sound become distorted. I.e. it's something specific exactly to voice processing (.voiceChat mode enables the same thing I believe) And I don't talk about audio recording/playing by app, I'm talking only about sound playing by PTT Framework to indicate PTT start. That's why comparing with CallKit has no meaning, since CallKit doesn't play such sound.

FYI, I'm not certain this will actually work correctly. Just like CallKit, the PTT framework needs to handle audio session activation so that it can modify the audio session configuration and then activate the session "itself". That model doesn't really work with a high level API like AVAudioRecorder. App creates AVAudioRecorder only after didActivate and switch to playAndRecord category. Do you mean AVAudioRecorder can alter some way Audio Session even in that case? but you should be configuring your session early as possible and specifically before "didActivate". Once the session is activated, it's already to late. Do you mean app should set playAndRecord category before didActivate? But when? After didBeginTransmitting and before didActivate, right?