Android 14 est compatible avec la dose sonore dans le framework audio et l'HAL audio en surveillant en permanence les mesures de la dose sonore et en avertissant les utilisateurs des niveaux d'exposition dangereux.
La dose sonore correspond à la mesure des niveaux de pression acoustique sur une période donnée. En surveillant la dose sonore, nous pouvons aider à protéger les utilisateurs des effets néfastes d'une exposition sonore excessive ou prolongée, offrant ainsi une meilleure protection auditive lorsque vous utilisez des écouteurs sur des appareils Android portables et réduisant les risques de déficience auditive.
Les nouvelles normes pour les appareils d'écoute sécurisés sont conformes aux exigences réglementaires de protection auditive dans les normes IEC62368-1 3e édition (nécessite une connexion) et EN50332-3 (accès limité aux abonnés), qui introduisent le concept de dose sonore.
La fonction de dose sonore permet aux OEM de respecter les nouvelles réglementations sur la sécurité auditive. Pour prendre en charge la dose sonore, les OEM doivent respecter les spécifications et les réglementations de l'interface pour toutes les personnalisations et certifications. Une implémentation OEM personnalisée peut contourner ou modifier l'implémentation par défaut d'AOSP de la dose sonore. Toutefois, nous vous recommandons vivement d'utiliser l'implémentation AOSP.
Calcul de la dose sonore
Les normes de la 3e édition de la norme CEI 62368-1 et de la norme EN 50332-3 améliorent la précision de la mesure de l'exposition au bruit 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 période glissante continue de sept jours des valeurs CSD cumulées est maintenue pour le calcul de la dose sonore.
Conformément à la section 10.6.3.2 de la troisième édition de la norme CEI 62368-1, si la valeur CSD atteint la limite de 100 %, le système avertit l'utilisateur des niveaux sonores à chaque augmentation de 100%. Si l'utilisateur ne confirme pas l'avertissement, le volume est réduit à la valeur de la classe 1 (RS1) de la source d'énergie de rayonnement prédéfinie de la table 39 de la norme CEI 62368-1.
Comme indiqué dans la section 10.6.3.3 de la troisième édition de la norme CEI 62368-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 la source d'énergie de rayonnement de classe 2 (RS2) du tableau 39 de la norme CEI 62368-1.
Pour être certifié conformément à ces réglementations et pour que les valeurs CSD soient plus pertinentes, le système doit utiliser des valeurs de sortie précises telles qu'elles sont perçues par les utilisateurs (par exemple, la sortie de lecture multimédia). Il est important que le calcul du CSD utilise des valeurs proches des niveaux de pression acoustique réels auxquels l'utilisateur est exposé.
Architecture
Selon l'emplacement où les images sont capturées, les caractéristiques matérielles et les effets des transducteurs peuvent influencer le niveau d'alimentation des images affichées. Pour obtenir une mesure précise du niveau de pression acoustique de sortie, nous avons étendu le HAL afin d'obtenir les valeurs MEL directement à partir du matériel sous-jacent et de tenir compte des effets possibles appliqués par le processeur de signal numérique (DSP) ou les propriétés des haut-parleurs, tels que l'impédance, la sensibilité et la réponse en fréquence.
Si le HAL ne peut pas fournir de valeurs MEL, le framework audio analyse et calcule le CSD en tant que mécanisme de remplacement. Ce calcul dans le framework audio est basé sur les informations sur la sortie affichée signalées par HAL et les trames envoyées au DSP audio.
La dose sonore introduit deux composants, SoundDoseHelper et SoundDoseManager,, comme illustré dans la figure 1:
Figure 1 : Composants architecturaux de la fonctionnalité de dose sonore.
SoundDoseHelper
La classe SoundDoseHelper, qui se trouve dans le processus systemserver, est le principal point de collecte de toutes les données de dosage du son pertinentes. La classe AudioService gère la classe SoundDoseHelper.
La classe SoundDoseHelper est responsable des éléments suivants:
- Gérer les nouvelles informations sur le dosage
- Valeurs de dose sonore persistantes
- Récupération de l'état en cas de plantage de
audioserver - Déclencher des notifications de l'UI 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 sur la dose sonore à partir du HAL ou les calcule en interne, en dernier recours, à partir des trames envoyées au HAL. La classe SoundDoseManager envoie les données de dose sonore à la classe SoundDoseHelper.
MelProcessor et MelAggregator
Si le 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 la communication avec AudioService.
Implémentation
Les extensions d'interface HIDL sont obsolètes à partir d'Android 14. Par conséquent, la nouvelle interface HAL permettant de récupérer les valeurs MEL calculées et d'émettre des avertissements d'exposition, appelée ISoundDose, est définie dans le HAL Audio AIDL. Toutefois, pour les implémentateurs qui ont besoin de plus de temps pour intégrer le HAL audio AIDL, nous proposons un HAL AIDL de dose de son autonome, qui offre l'interface ISoundDoseFactory. Cette fonctionnalité sera abandonnée à 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 appels de retour qui informent le framework de 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 les rapports CSD. Sans cette implémentation de rappel, une implémentation de remplacement sur AudioFlinger est utilisée pour calculer les estimations des valeurs CSD.
Prise en charge de l'AIDL autonome de la dose sonore
Tant que les OEM ne peuvent pas 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);
}
Compatibilité de Sound Dose avec l'Audio HAL AIDL
L'interface de dose sonore est prise en charge à long terme dans le HAL audio AIDL en étendant l'interface IModule, comme illustré 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 troisième édition de la norme IEC62368-1 et dans la norme EN50332-3. Il n'existe donc pas d'API externes.
Les OEM peuvent certifier leurs appareils en implémentant les nouvelles interfaces HAL et en fournissant des données MEL précises pour la CSD au framework audio (recommandé), ou en fournissant une implémentation personnalisée de la dose sonore.
Activer le calcul de la dose sonore
Par défaut, AOSP est compatible avec la logique de sécurité auditive qui garantit la certification avec les normes EN50332-2 et IEC62368-1 10.6.5 existantes.
Dans Android 14, le calcul de la dose sonore est désactivé par défaut.
Suivez les consignes ci-dessous pour activer le calcul de la dose sonore à partir d'Android 14-QPR1.
Si les réglementations sur la dose sonore sont appliquées dans votre pays, vérifiez si
config_safe_media_volume_enableddansconfig.xmlest défini surtrue.Pour être conformes aux normes EN50332-3 et IEC62368-1 10.6.3, les fournisseurs doivent superposer l'indicateur
config_safe_sound_dosage_enableddansconfig.xmlàtrue. Pour les appareils compatibles avec le décodage offload et qui n'implémentent pas les interfaces HAL de dose sonore,config_safe_sound_dosage_enabledne doit pas être défini surtrue. Dans ce cas, définirconfig_safe_sound_dosage_enabledsurtruepeut 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 de pays et des valeurs des indicateurs, le CSD ou les anciens niveaux de sécurité auditive (implémentés avant Android 14) sont calculés.
Figure 2. Activez 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 effectuer une validation par rapport aux cas de test VTS définis par VtsHalAudioCoreTargetTest pour l'implémentation de l'HAL Audio AIDL IModule ou par VtsHalSoundDoseFactoryTargetTest pour l'implémentation de l'HAL AIDL de dose sonore autonome.