I've got an idea how to deal with slow/failed connection to server: user initiates outgoing PTT app gets didBeginTransmitting app switches to PTServiceStatus.connecting 4a. if connection established app prepares audio recording, switches to PTServiceStatus.ready and waits didActivate. 4b. if connection (or floor claim) fails app just terminates PTT The question here is: can I be sure PTT Framework will not send didActivate until app not set .ready?

@DTS Engineer thank you for your answer! But I'm a little bit confused. Do You want to say it's legitimate to create audio recording entities even if Audio Session is not activated? It looks like my main mistake is I always thought active audio session is mandatory condition to start work with audio subsystem 🤔 update: I think the source of my mistake is official documentation: Before recording and transmitting audio, wait for the framework to call channelManager(_:didActivate:). update 2: another thing I'm worrying about is establishing connection to audio receiving server. It can take some time and user will get audio notification about he/she may start talk before audio can be really sent. This means app has to implement some recorded audio buffering. On other side, connection to server can fail (especially if PTT started from background) and it can happen with significant delay, and from user point of view it will look like he/she actually successfully recorded audio (at least some peace of audio). Also user can fail to "claim floor" due to race condition (and it's highly possible with more than 2 participants in room, we've met it already). And if take into account PTT Framework doesn't offer any "fail" notification I'm really confused how to deal with it...

@DTS Engineer, sorry, it looks like I was not clear enough. Actually I don't care too much about AVAudioEngine based implementation right now. But I need to find some way to get PTT working with AudioToolbox framework (i.e. with something like https://github.com/RSATom/PTTPlayground/blob/49f4dedfee192a75789fd7b3566f78123afa7a86/PTTPlayground/PTT.swift#L223-L346) The reason is WebRTC library uses AudioToolbox framework internally, and I would prefer to find some simple solution, rather than do significant refactoring to switch it to AVAudioEngine. So right now I just need to get conformation if it's really possible or not.

@DTS Engineer I've got your point. Thank you! But let me ask the same different way then - is there any way to avoid issue with PTT Start Audio Notification with Voice Processing Audio Unit? P.S.: I've moved Audio Session management to thread sending didBeginTransmittingFrom (I've used atomics for threads synchronisation) in demo app. I've added very basic implementation using kAudioUnitSubType_VoiceProcessingIO to demo app. And still see issue :( And with Audio Unit it doesn't matter if .voiceChat mode enabled or not...

@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?