Dose sonore

Android 14 prend en charge la dose sonore dans le cadre audio et Audio HAL en surveillant en permanence les mesures de dose sonore et en émettant des avertissements aux utilisateurs concernant les niveaux d'exposition nocifs.

La dose sonore est une mesure des niveaux de pression acoustique sur une période donnée. En surveillant la dose sonore, nous pouvons contribuer à protéger les utilisateurs contre les effets néfastes d'une exposition sonore excessive ou prolongée, offrant ainsi une meilleure protection auditive lors de l'utilisation d'écouteurs sur des appareils Android portables et minimisant le risque de déficience auditive.

Les nouvelles normes pour les appareils d'écoute sécurisée sont conformes aux exigences réglementaires en matière de protection auditive de la 3e édition IEC62368-1 (connexion requise) et EN50332-3 (accès limité aux abonnés), qui introduisent la notion de dose sonore.

La fonction de dose sonore permet aux équipementiers de suivre les nouvelles réglementations en matière de sécurité auditive. Pour prendre en charge la dose sonore, les OEM doivent suivre les spécifications et réglementations d’interface pour toutes les personnalisations et certifications. Une implémentation OEM personnalisée peut contourner ou modifier l’implémentation par défaut de l’AOSP en matière de dose sonore. Cependant, l’utilisation de l’implémentation AOSP est fortement recommandée.

Calcul de la dose sonore

Les normes IEC62368-1 3e édition et EN50332-3 augmentent la précision de la mesure de l'exposition sonore en calculant la dose sonore calculée (CSD). Le CSD est calculé en intégrant les niveaux d'exposition momentanés (MEL) au fil du temps. Une fenêtre continue de sept jours de valeurs CSD accumulées est maintenue pour le calcul de la dose sonore.

Conformément à la section 10.6.3.2 de la 3e édition de la norme IEC62368-1, si la valeur CSD atteint la limite de 100 %, le système alerte l'utilisateur des niveaux sonores à chaque augmentation de 100 %. Si l'utilisateur n'acquitte pas de l'avertissement, le volume diminue jusqu'à la valeur prédéfinie de la classe d'énergie de rayonnement 1 (RS1) du tableau 39 de la norme CEI62368-1.

Comme mentionné dans la section 10.6.3.3 de la 3e édition de la CEI62368-1, en plus des avertissements de dose sonore, le système doit déclencher un avertissement basé sur l'exposition chaque fois que la valeur MEL dépasse la valeur de source d'énergie de rayonnement de classe 2 (RS2) du tableau 39 de la CEI62368. -1.

Pour être certifié conforme à ces réglementations et rendre les valeurs CSD plus pertinentes, le système doit utiliser des valeurs de sortie précises telles que perçues par les utilisateurs (telles que la sortie de lecture multimédia). Il est important que le calcul CSD utilise des valeurs proches des niveaux de pression acoustique réels auxquels l'utilisateur est exposé.

Architecture

Selon l'endroit où les images sont capturées, les caractéristiques matérielles et les effets des transducteurs peuvent influencer le niveau de puissance des images rendues. Pour obtenir une mesure précise du niveau de pression acoustique de sortie, nous avons étendu le HAL pour obtenir les valeurs MEL directement à partir du matériel sous-jacent et prendre en compte les effets possibles appliqués par le processeur de signal numérique (DSP) ou les propriétés du haut-parleur, telles que l'impédance, la sensibilité, et la réponse en fréquence.

Si le HAL ne peut pas fournir de valeurs MEL, en tant que mécanisme de secours, le framework audio analyse et calcule le CSD. Ce calcul dans le cadre audio est basé sur les informations sur la sortie rendue rapportée par HAL et les trames envoyées au DSP audio.

La dose sonore introduit deux composants, SoundDoseHelper et SoundDoseManager, comme le montre la figure 1 :

sound_dose_arch

Figure 1. Composants architecturaux de la fonction de dose sonore.

SoundDoseHelper

La classe SoundDoseHelper , qui réside dans le processus systemserver , est le principal point de collecte de toutes les données de dosage sonore pertinentes. La classe AudioService gère la classe SoundDoseHelper .

La classe SoundDoseHelper est responsable des éléments suivants :

  • Gestion des nouvelles informations de dosage
  • Valeurs de dose sonore persistantes
  • Récupération de l'état en cas de crash audioserver
  • Déclenchement des notifications de l'interface utilisateur du système
  • Baisser le volume

SoundDoseManager

La classe SoundDoseManager , qui réside dans le processus audioserver et fait partie de la classe AudioFlinger , collecte les données de dose sonore du HAL ou les calcule en interne, en guise de solution de repli, à partir des trames envoyées au HAL. La classe SoundDoseManager envoie les données de dose sonore à la classe SoundDoseHelper .

MelProcessor et MelAggregator

Si HAL ne peut pas fournir de valeurs MEL, les utilitaires MelProcessor et MelAggregator de libaudioutils sont utilisés pour le calcul de la dose sonore interne.

Dans la classe MelProcessor , le calcul principal est effectué sur un tampon avec des échantillons audio en appelant MelProcessor::process(const void* buffer, size_t bytes) . Les OEM peuvent utiliser MelProcessor dans leur implémentation HAL si nécessaire.

La classe MelAggregator reçoit les valeurs MEL de différents ports audio et calcule la valeur CSD avec une fenêtre glissante de sept jours. La méthode MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) exécute la logique. Les résultats sont envoyés à la classe SoundDoseManager pour communication avec AudioService .

Mise en œuvre

Les extensions d'interface HIDL sont obsolètes à partir d'Android 14, de sorte que la nouvelle interface HAL pour récupérer les valeurs MEL calculées et émettre des avertissements d'exposition, nommée ISoundDose , est définie dans le cadre de AIDL Audio HAL . Cependant, pour les implémenteurs qui ont besoin de plus de temps pour intégrer AIDL Audio HAL, nous disposons d'une dose sonore autonome AIDL HAL , qui offre l'interface ISoundDoseFactory . Cela sera obsolète à l’avenir.

Les méthodes HAL pour la prise en charge de la dose sonore sont présentées dans l'exemple de code suivant :

/**
 * This interface provides functions related to sound exposure control required for compliance to
 * EN/IEC 62368-1 3rd edition. Implementing this interface is mandatory for devices for which
 * compliance to this standard is mandated and implementing audio offload decoding or other direct
 * playback paths where volume control happens below the audio HAL.
 */
@VintfStability
interface ISoundDose {
    /**
     * Max value in dBA used for momentary exposure warnings as defined by IEC62368-1
     * 3rd edition. This value represents the default RS2 upper bound.
     */
    const int DEFAULT_MAX_RS2 = 100;
    /** Min value of the RS2 threshold in dBA as defined by IEC62368-1 3rd edition. */
    const int MIN_RS2 = 80;

    /**
     * Sets the RS2 upper bound used for momentary exposure warnings. Default value is
     * DEFAULT_MAX_RS2 as specified in IEC62368-1 3rd edition.
     *
     * @param rs2ValueDbA custom RS2 upper bound to use
     * @throws EX_ILLEGAL_ARGUMENT if rs2ValueDbA is greater than DEFAULT_MAX_RS2 or lower
     *                             than MIN_RS2
     */
    void setOutputRs2UpperBound(float rs2ValueDbA);

    /**
     * Gets the RS2 upper bound used for momentary exposure warnings.
     *
     * @return the RS2 upper bound in dBA
     */
    float getOutputRs2UpperBound();

    /**
     * Registers the HAL callback for sound dose computation. If sound dose is supported
     * the MEL values and exposure notifications will be received through this callback
     * only. The internal framework MEL computation will be disabled.
     * It is not possible to unregister the callback. The HAL is responsible to provide
     * the MEL values throughout its lifecycle.
     *
     * @param callback to use when new updates are available for sound dose
     */
    void registerSoundDoseCallback(in IHalSoundDoseCallback callback);

    @VintfStability
    oneway interface IHalSoundDoseCallback {
        /**
         * Called whenever the current MEL value exceeds the set RS2 upper bound.
         *
         * @param currentDbA the current MEL value which exceeds the RS2 upper bound
         * @param audioDevice the audio device where the MEL exposure warning was recorded
         */
        void onMomentaryExposureWarning(float currentDbA, in AudioDevice audioDevice);

        @VintfStability
        parcelable MelRecord {
            /**
             * Array of continuously recorded MEL values >= MIN_RS2 (1 per second).
             * First value in the array was recorded at 'timestamp'.
             */
            float[] melValues;
            /**
             * Corresponds to the time in seconds, as reported by CLOCK_MONOTONIC, when
             * the first MEL entry in melValues was recorded. The timestamp values have
             * to be consistent throughout all audio ports, equal timestamp values will
             * be aggregated.
             */
            long timestamp;
        }

        /**
         * Provides a MelRecord containing continuous MEL values sorted by timestamp.
         * Note that all the MEL values originate from the audio device specified by audioDevice.
         * In case values from multiple devices need to be reported, the caller should execute
         * this callback once for every device.
         *
         * @param melRecord contains the MEL values used for CSD
         * @param audioDevice the audio device where the MEL values were recorded
         */
        void onNewMelValues(in MelRecord melRecord, in AudioDevice audioDevice);
    }
}

La nouvelle interface HAL implémente des rappels qui informent le framework sur l'exposition momentanée et fournissent des valeurs MEL chaque fois que le niveau de sortie dépasse RS1. Lorsque ces interfaces sont implémentées, le framework les utilise pour le reporting CSD. Sans cette implémentation de rappel, une implémentation de secours sur AudioFlinger est utilisée pour calculer les estimations des valeurs CSD.

Prise en charge AIDL autonome pour la dose sonore

Jusqu'à ce que les OEM puissent intégrer la dose sonore dans le HAL audio AIDL, ils peuvent utiliser l'API AIDL autonome ISoundDoseFactory comme solution de contournement. ISoundDoseFactory utilise l'interface ISoundDose , comme illustré dans l'exemple de code suivant :

@VintfStability
interface ISoundDoseFactory {
    /**
     * Retrieve the sound dose interface for a given audio HAL module name.
     *
     * If a device must comply to IEC62368-1 3rd edition audio safety requirements and is
     * implementing audio offload decoding or other direct playback paths where volume control
     * happens below the audio HAL, it must return an instance of the ISoundDose interface.
     * The same instance must be returned during the lifetime of the HAL module.
     * If the HAL module does not support sound dose, null must be returned, without throwing
     * any errors.
     *
     * @param module for which we trigger sound dose updates.
     * @return An instance of the ISoundDose interface implementation.
     * @throws EX_ILLEGAL_STATE If there was an error creating an instance.
     */
    @nullable ISoundDose getSoundDose(in @utf8InCpp String module);
}

Dose sonore Prise en charge AIDL Audio HAL

L'interface de dose sonore est prise en charge à long terme dans le cadre de AIDL Audio HAL en étendant l'interface IModule , comme indiqué dans l'exemple de code suivant :

@VintfStability
interface IModule {
…
    /**
     * Retrieve the sound dose interface.
     *
     * If a device must comply to IEC62368-1 3rd edition audio safety requirements and is
     * implementing audio offload decoding or other direct playback paths where volume control
     * happens below the audio HAL, it must return an instance of the ISoundDose interface.
     * The same instance must be returned during the lifetime of the HAL module.
     * If the HAL module does not support sound dose, null must be returned, without throwing
     * any errors.
     *
     * @return An instance of the ISoundDose interface implementation.
     * @throws EX_ILLEGAL_STATE If there was an error creating an instance.
     */
    @nullable ISoundDose getSoundDose();
}

Cette fonctionnalité est une implémentation d'une nouvelle réglementation décrite dans la 3e édition de la CEI62368-1 et de la EN50332-3, il n'y a donc pas d'API orientée vers l'extérieur.

Les OEM peuvent certifier leurs appareils en implémentant les nouvelles interfaces HAL et en fournissant des données MEL précises pour CSD au cadre audio (recommandé), ou en fournissant une implémentation de dose sonore personnalisée.

Activer le calcul de la dose sonore

Par défaut, AOSP prend en charge la logique de sécurité auditive qui garantit la certification selon les normes EN50332-2 et IEC62368-1 10.6.5 existantes.

Sous Android 14, le calcul de la dose sonore est désactivé par défaut.

Utilisez les instructions suivantes pour activer le calcul de la dose sonore à partir d’Android 14-QPR1.

  • Si les réglementations sur la dose sonore sont en vigueur dans votre pays, vérifiez si config_safe_media_volume_enabled dans config.xml est défini sur true .

  • Pour être conformes aux normes EN50332-3 et IEC62368-1 10.6.3, les fournisseurs doivent superposer l'indicateur config_safe_sound_dosage_enabled dans config.xml sur true . Pour les appareils prenant en charge le décodage de déchargement et n'implémentant pas les interfaces HAL de dose sonore , config_safe_sound_dosage_enabled ne doit pas être défini sur true . Dans de tels cas, définir config_safe_sound_dosage_enabled sur true peut entraîner des valeurs CSD inexactes et des problèmes de certification pour les normes d'audition de sécurité.

Le graphique de décision suivant décrit la logique qui détermine si, en fonction des restrictions nationales et des valeurs des drapeaux, les niveaux de sécurité auditive CSD ou existants (mis en œuvre avant Android 14) sont calculés.

enable_csd

Figure 2. Activer le calcul de la dose sonore (la logique est ajoutée dans Android 14-QPR1).

Validation

Lors de l'implémentation de l'interface HAL pour la dose sonore, les OEM doivent valider par rapport aux cas de test VTS définis par VtsHalAudioCoreTargetTest pour l'implémentation IModule AIDL Audio HAL, ou par VtsHalSoundDoseFactoryTargetTest pour l'implémentation autonome de dose sonore AIDL HAL.