Capture simultanée

Android 10 améliore l'expérience utilisateur qui nécessite plusieurs captures audio actives simultanément, par exemple, si l'utilisateur souhaite contrôler un appel VoIP ou un enregistreur vidéo avec des commandes vocales fournies par un service d'accessibilité.

Le cadre audio implémente la politique permettant uniquement à certaines applications privilégiées de capturer en même temps que des applications régulières.

La politique de concurrence est implémentée en faisant taire son audio capturé plutôt qu'en empêchant une application de commencer la capture. Cela permet au framework de traiter dynamiquement les changements dans le nombre et les types de cas d'utilisation de capture active, sans empêcher une application de commencer la capture dans un cas où elle peut récupérer un accès complet au microphone après qu'une autre application a terminé la capture.

La conséquence pour la HAL audio et le sous-système audio est qu'ils doivent prendre en charge plusieurs flux d'entrée actifs simultanément, même si dans certains cas, un seul flux fournit de l'audio non silencieux à un client actif.

Exigences CDD

Voir CDD pour les conditions requises pour la prise en charge de la capture simultanée.

Capturez des situations à partir de HAL audio

Un scénario de capture simultanée peut entraîner différentes situations en termes de nombre de flux d'entrée actifs, de sélection de périphérique d'entrée ou de configuration de prétraitement.

La simultanéité peut se produire entre les éléments suivants :

  • Plusieurs flux d'entrée du processeur d'application (AP)
  • Flux d'entrée et appel vocal
  • Flux d'entrée et un DSP audio mettant en œuvre une détection de mot clé à faible consommation

Activité simultanée des flux d'entrée AP

Le fichier de configuration de la politique audio audio_policy_configuration.xml est utilisé par le framework audio pour déterminer combien de flux d'entrée peuvent être ouverts et actifs simultanément.

Au minimum, la couche HAL audio doit prendre en charge au moins une instance de chaque profil d'entrée ( mixPort du rôle sink ) répertorié dans le fichier de configuration ouvert et actif .

Sélection de l'appareil

Lorsque plusieurs clients actifs sont attachés au même flux d'entrée HAL, le framework sélectionne le périphérique approprié pour ce flux d'entrée en fonction de la priorité des cas d'utilisation.

Lorsque plusieurs flux d'entrée sont actifs, chaque flux peut avoir une sélection de périphérique différente.

Si la technologie est compatible, il est recommandé que la HAL audio et le sous-système autorisent la capture de différents flux à partir de différents appareils, tels qu'un casque Bluetooth et un micro intégré.

S'il y a une incompatibilité (par exemple, deux appareils partagent la même interface audio numérique ou back-end), la HAL audio doit choisir quel flux contrôle la sélection de l'appareil.

Dans ce cas:

  • L'état résultant doit être cohérent et proposer la même sélection d'appareils lorsque le même scénario se répète.
  • Lorsque l'état de concurrence prend fin, le flux actif restant doit être acheminé vers l'appareil initialement demandé sur ce flux.

Si un ordre de priorité est défini par le HAL audio entre les cas d'utilisation actifs, suivez le même ordre que celui trouvé dans source_priority() dans frameworks/av/services/audiopolicy/common/include/policy.h

Sélection de pré-traitement

Le framework audio peut demander un prétraitement sur un flux d'entrée à l'aide des méthodes HAL addEffect() ou removeEffect() .

Pour le prétraitement sur un flux d'entrée donné, le framework audio n'active que la configuration correspondant au cas d'utilisation actif le plus prioritaire sur le flux d'entrée. Cependant, il peut y avoir un certain chevauchement lors de l'activation et de la désactivation du cas d'utilisation, entraînant l'exécution de deux processus actifs simultanés (par exemple, deux instances d'annuleur d'écho) sur le même flux d'entrée. Dans ce cas, l'implémentation HAL choisit quelle demande est acceptée ; il garde une trace des demandes actives et restaure l'état correct lorsque l'un ou l'autre des processus est désactivé.

Lorsque plusieurs flux de capture sont actifs simultanément, différentes requêtes de prétraitement peuvent être exécutées sur différents flux.

Les implémentations de HAL et du sous-système audio doivent permettre l'application de différents prétraitements à différents flux, même s'ils partagent le même périphérique d'entrée. C'est-à-dire que le prétraitement doit être appliqué après le démultiplexage des flux à partir de la source de capture principale.

Si ce n'est pas possible pour des raisons techniques sur un sous-système audio donné, la couche HAL audio doit appliquer des règles de priorité similaires à celles répertoriées dans Sélection de périphérique .

Appel vocal simultané et capture à partir du point d'accès

La capture à partir du point d'accès peut se produire pendant qu'un appel vocal est actif. Cette situation n'est pas nouvelle dans Android 10 et n'est pas directement liée à la fonctionnalité de capture simultanée, mais il est utile de mentionner les directives pour ce scénario.

Deux types différents de capture depuis le point d'accès sont nécessaires pendant un appel.

Capture d'appel RX et TX

La capture des appels RX et TX est déclenchée par l'utilisation de la source audio AudioSource.VOICE_UPLINK ou AudioSource.VOICE_DOWNLINK et/ou de l'appareil AudioDevice.IN_TELEPHONY_RX .

Les HAL audio doivent être AudioDevice.IN_TELEPHONY_RX sur le profil d'entrée ( mixPort du récepteur de rôle) avec une route disponible à partir du périphérique sink .

Lorsqu'un appel est connecté (le mode audio est AudioMode.IN_CALL ), il devrait être possible d'avoir au moins un flux de capture actif à partir du périphérique AudioDevice.IN_TELEPHONY_RX .

Capture à partir de périphériques d'entrée lorsqu'un appel est actif

Lorsqu'un appel est actif (le mode audio est AudioMode.IN_CALL ), il doit être possible d'ouvrir et d'activer les flux d'entrée du point d'accès comme spécifié dans la section Activité simultanée des flux d'entrée du point d'accès .

Cependant, la priorité pour la sélection de l'appareil et le prétraitement doit toujours être déterminée par l'appel vocal en cas de conflit avec les demandes des flux d'entrée AP.

Capture simultanée depuis DSP et AP

Lorsque le sous-système audio contient un DSP prenant en charge les fonctions de détection de contexte audio ou de mots clés à faible puissance, la mise en œuvre doit prendre en charge la capture simultanée à partir du point d'accès et du DSP audio. Cela inclut à la fois la capture par le DSP pendant la phase de détection initiale et la capture par le point d'accès avec AudioSource.HOTWORD après le déclenchement de la détection par le DSP.

Cela doit être reflété par l'indicateur de capture simultanée signalé par le déclencheur sonore HAL via le descripteur d'implémentation : ISoundTriggerHw.Properties.concurrentCapture = true .

La couche HAL audio doit également exposer et entrer un profil spécifique pour la capture de mot clé identifié par l'indicateur AudioInputFlag.HW_HOTWORD . L'implémentation doit prendre en charge l'ouverture et l'activation d'un nombre de flux sur ce profil au moins égal au nombre de modèles sonores pouvant être chargés simultanément par le déclencheur sonore HAL.

La capture à partir de ce profil d'entrée doit être possible pendant que d'autres profils d'entrée sont actifs.

Implication pour les implémentations de l'assistant

Exigences relatives à l'utilisation des données et à la notification des utilisateurs

Étant donné que l'utilisation simultanée du micro, en cas d'abus, peut entraîner une fuite des données privées de l'utilisateur, nous avons besoin que les conditions et garanties suivantes soient appliquées aux applications préchargées privilégiées qui demandent à détenir le rôle d'assistant.

  • Les données collectées via le microphone ne doivent pas quitter l'appareil à moins que l'utilisateur n'interagisse avec l'assistant. Par exemple, après le déclenchement du mot clé.
  • Les applications qui écoutent simultanément doivent fournir des repères visuels à l'utilisateur après la détection du mot clé. Cela aide les utilisateurs à comprendre que d'autres conversations passeraient par une application différente, telle que l'Assistant.
  • Les utilisateurs doivent avoir la possibilité de désactiver le microphone ou les déclencheurs de l'assistant.
  • Lorsque des enregistrements audio sont stockés, les utilisateurs doivent avoir la possibilité d'accéder, de consulter et de supprimer des enregistrements à tout moment.

Améliorations fonctionnelles pour Android 10

Les assistants ne se bloquent pas

Sur Android 9 ou une version antérieure, lorsqu'il y a deux assistants toujours activés sur l'appareil, un seul d'entre eux peut écouter son mot clé. Par conséquent, il était nécessaire de basculer entre les deux assistants. Dans Android 10, l'assistant par défaut peut écouter en même temps que l'autre assistant. Cela se traduit par une expérience beaucoup plus fluide pour les utilisateurs avec les deux assistants.

Applications maintenant le micro ouvert

Lorsque des applications comme Shazam ou Waze maintiennent le micro ouvert, l'assistant par défaut peut toujours écouter le mot clé.

Pour les applications Assistant autres que celles par défaut, il n'y a aucun changement de comportement pour Android 10.

Exemple d'implémentation audio HAL

Un exemple d'implémentation audio HAL conforme aux directives de ce document peut être trouvé dans AOSP .