PushToTalk

What problem are you actually having?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

In the above scenario, the sound recorded with AVAudioRecorder is all noise.

In the above scenario, the sound recorded with AVAudioRecorder is all noise.

Like most of our higher-level audio APIs, AVAudioRecorder will work with the PushToTalk (or CallKit) framework. The issue here is that the PushToTalk framework is tightly integrated into our audio infrastructure and, as part of that integration, the activation of your audio session MUST be triggered by the PushToTalk system, NOT your app.

Unfortunately, AVAudioRecorder does its own activation, which will then break the PTT system. You'll need to use a lower-level audio API, typically AVAudioEngine. For an example of how the audio side of this, please see the Speakerbox CallKit sample.

It may seem odd that I'm recommending a CallKit sample, but the thing to understand is that CallKit and the PushToTalk framework share exactly the same underlying implementation. Both frameworks are managed callservicesd and, internally, they actually share a common implementation, particularly when it comes to the audio system.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Firstly, I am using AVAudioEngine for recording implementation. We are not currently using CallKit. The audio recorded by AVAudioEngine still has noise in the above scenario (when PushToTalk is turned on and the app is switched to the background, the app is in a state of long-term survival in the background, and then AVAudioEngine recording is started by clicking the Bluetooth device button), but I found that the audio recorded after clicking the intercom button on the PushToTalk interface has no noise. The audio recorded by clicking the Bluetooth device button is noise. The method called by Bluetooth devices is (requestBeginTransmitting), which enables AVAudioEngine recording in the (channelManager: PTChannelManager, didActivate audioSession: AVAudioSession) method. Is there any additional setting for the intercom button on the PushToTalk interface?

The “Zello Walkie Talkie” app's intercom function is perfectly implemented

The audio recorded by clicking the Bluetooth device button is noise. The method called by Bluetooth devices is (requestBeginTransmitting), which enables AVAudioEngine recording in the (channelManager: PTChannelManager, didActivate audioSession: AVAudioSession) method.

First off, I want to clarify that possible background activation paths here:

1. The user pushes the "talk" button using the systems on screen UI.

2. The app is Bluetooth authorized and adds directly calls requestBeginTransmitting() because of a BLE event from a proprietary accessory.

3. The app has set setAccessoryButtonEventsEnabled(...) to true and the user sends non-HFP* remote control event to the PTT system. The standard example of this is pressing the "play" button on an A2DP/HFP Bluetooth accessory that's currently in playback mode.

*HFP events are automatically handled by the system through the standard delegate system.

Expanding on #3, this is how the PTT system provides its own support for the experience many PTT apps had previously implemented that allowed PTT apps to be controlled through "standard" A2DP/HFP headset. This user experience is reasonably straightforward, but the details of how it actually functions are more complicated than they look.

Based on the fact you're calling requestBeginTransmitting(), I'm going to assume you're referring to #2, but please let me know if I've misunderstood. That leads to here:

The audio recorded by AVAudioEngine still has noise in the above scenario (when PushToTalk is turned on and the app is switched to the background, the app is in a state of long-term survival in the background, and then AVAudioEngine recording is started by clicking the Bluetooth device button), but I found that the audio recorded after clicking the intercom button on the PushToTalk interface has no noise.

The short answer here is that I think there's an issue with the details of your activation code. The thing to understand here is that #2 above doesn't actually involve the audio system AT ALL. The system uses Bluetooth authorization to confirm that you're "allowed" to trigger requestBeginTransmitting from that background, after which activation proceeds exactly as it would in the foreground.

However, what tends to break down here goes back to this issue:

The issue here is that the PushToTalk framework is tightly integrated into our audio infrastructure and, as part of that integration, the activation of your audio session MUST be triggered by the PushToTalk system, NOT your app.

Expanding on that point, the problem here is that "setActive" will work in the foreground (because the foreground app always has control over the audio system) but will NOT work correctly in the background. That dynamic is why PTT/CallKit apps often have audio problems that only show up in the foreground.

That then leads to here...

I found that the audio recorded after clicking the intercom button on the PushToTalk interface has no noise.

The only difference between #2 and #1/#3 is that #2 starts with your app calling requestBeginTransmitting(), which #1/#3 both "start" with your app receiving channelManager(_:channelUUID:didBeginTransmittingFrom:). That means any difference your app is experiencing is probably tied to whatever your app is doing when it starts that process. Typically that means your either reconfiguring your audio objects at the wrong time, or you're directly calling setActive().

Is there any additional setting for the intercom button on the PushToTalk interface?

No.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

This is my PTT code 1: Click on the intercom button and Bluetooth device button on the PushToTalk interface. The recording all starts in this method (channelManager: PTChannelManager, didActivate AudioSession: AVAudioSession) 2: There is no problem with recording audio by clicking the intercom button on the PushToTalk interface. But there are problems with clicking on recorded audio on Bluetooth devices (all noise or no sound during playback) 3: The method called after the application switches to the background (setupChannelManager (channelUUID: UUID)) 4: The method called by clicking the Bluetooth button (requestBeginTransmitting()) 5: The above scenarios are all when the application switches to the background (the application has set the background to keep alive and Background Modes) 6: All functions are normal without any issues when the application switches to the frontend.