Concurrent Capture in Android 13

Android 13 enhances the user experience when several active audio captures are required, such as when a user wants to use voice commands provided by an accessibility service to operate a VoIP call or video recorder. In this article, we will be looking at how Concurrent Capture works in Android 13, and how it is improved in this Android version, but first, we will understand what concurrent capture actually means in Android Subsystem.

Instead of stopping an application from beginning to capture, the concurrency policy is enforced by muting its captured audio. As a result, an app may begin capturing in situations where it can regain full access to the microphone after another app has stopped capturing since the framework can adapt dynamically to changes in the number and types of active capture use cases.

Which apps can use Concurrent Capture?

Only a few privileged apps are permitted to capture simultaneously with non-privileged apps under the policy that is implemented by the audio framework. The audio HAL and audio subsystem must handle multiple active input streams at once as a result, even though only one stream may occasionally be supplying non-silent audio to an active client.

Capture circumstances with HAL Audio

The number of active input streams, choice of the input device, and preprocessing configuration might all vary as a result of a concurrent capture scenario, which we have discussed in the previous Geeks for Geeks article. 

Concurrency between the following is possible

1. Streams of data and a voice call
2. Several application processor input streams (AP)
3. Input streams and a low-power hotword detection implemented by an audio DSP

How the Audio Stream is Determined?

The audio framework uses the audio policy configuration.xml audio policy configuration file to specify how many input streams can be opened and active at once. Each input profile (mixPort of role sink) stated in the open and active configuration file must be supported by the audio HAL in at least one instance.

How Android Framework works to Choose the Source

The framework chooses the best device for this input stream based on use case priority when multiple active clients are hooked to the same HAL input stream. Each input stream can choose a different device while many input streams are open.

GeekTip: It is advised that the audio HAL and subsystem allow different streams to be captured from different sources, such as a Bluetooth headset and built-in mic if the technology is compatible.

The audio HAL must decide which stream controls the device selection in the event of an incompatibility (for example, when two devices share the same digital audio interface or back end).

Understanding the AP and Simultaneous Voice Call

While a voice call is ongoing, the AP can be captured. Despite the fact that this scenario isn’t new in Android 10 and isn’t specifically related to the concurrent capture capability, it’s still important to note the rules for it. During a call, two separate kinds of capture from the AP are required, which are:

1. Call RX and TX routes being captured
2. Taking notes with an input device (for example, a built-in mic).

Understanding the DSP and AP Voice Call

The implementation should support concurrent capture from the AP and the audio DSP when the audio subsystem has a DSP enabling low-power audio context or hotword detection functionalities. Both the capture by the AP using AudioSource and the capture by the DSP during the initial detection phase are included in this. Following detection, the DSP activates HOTWORD. This should be mirrored by the concurrent capture flag ISoundTriggerHw.Properties.concurrentCapture = true supplied by the sound trigger HAL via the implementation descriptor.

A hotword input profile is designated by the flag AudioInputFlag.HW HOTWORD should be exposed by the audio HAL as well. The number of streams that can be opened and turned on by the implementation on this profile should be at least as many as the sound trigger HAL can load concurrently.

Understanding Improvements that happened over Android 13

When there are two always-on Assistants on an Android smartphone running version 9 or lower, only one of them may be listening for its hotword. As a result, switching between the two Assistants was necessary. The default Assistant and another Assistant can both listen at the same time in Android 10. Users of both Assistants experience a vastly improved level of smoothness as a result.

Open mic while using apps:

The default Assistant may continue listening for the hotword even while apps like Shazam or Waze hold the microphone open. There is no difference in behavior for non-default Assistant apps in Android 10.

Conclusion

The device’s internal microphone, external microphone, or audio interface are often the sources of audio input. A phone call can also provide audio input. Hope this article helped you learn how to use concurrent capture in your android application, delivering the audio signal from the same source to multiple apps that want to record audio simultaneously might be challenging.