Android 14 est compatible avec la dose sonore dans le framework audio et le HAL audio. Pour ce faire, il surveille en continu les mesures de la dose sonore et envoie des avertissements aux utilisateurs concernant les niveaux d'exposition dangereux.
La dose sonore est une mesure des niveaux de pression acoustique sur une période donnée. En surveillant la dose sonore, nous pouvons aider à protéger les utilisateurs contre les effets néfastes d'une exposition excessive ou prolongée au son, 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 dans les normes IEC62368-1, 3e édition (connexion requise) 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 protection de l'audition. Pour prendre en charge la dose sonore, les OEM doivent respecter les spécifications d'interface et les réglementations pour toutes les personnalisations et certifications. Une implémentation OEM personnalisée peut contourner ou modifier l'implémentation AOSP par défaut 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 (DSC). La CSD est calculée en intégrant les niveaux d'exposition momentanée (NEM) au fil du temps. Une période glissante continue de sept jours de valeurs CSD cumulées est conservée 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 sur les niveaux sonores à chaque augmentation de 100 %. Si l'utilisateur ne confirme pas l'avertissement, le volume est réduit à la valeur prédéfinie de la classe 1 de source d'énergie de rayonnement (RS1) du tableau 39 de la norme IEC62368-1.
Comme indiqué dans la section 10.6.3.3 de la 3e édition de la norme IEC62368-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 classe de source d'énergie de rayonnement 2 (RS2) du tableau 39 de la norme IEC62368-1.
Pour obtenir la certification avec 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 (comme la sortie de lecture multimédia). Il est important que le calcul de la CSD utilise des valeurs proches des niveaux de pression acoustique auxquels l'utilisateur est réellement 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 affichées. Pour obtenir une mesure précise du niveau de pression acoustique de sortie, nous avons étendu la HAL afin d'obtenir les valeurs MEL directement à partir du matériel sous-jacent et de tenir compte des éventuels effets appliqués par le processeur de signaux numériques (DSP) ou les propriétés des enceintes, telles que l'impédance, la sensibilité et la réponse en fréquence.
Si la HAL ne peut pas fournir de valeurs MEL, le framework audio analyse et calcule le CSD comme mécanisme de secours. Ce calcul dans le framework audio est basé sur les informations concernant la sortie rendue signalées par HAL et sur les frames envoyés au DSP audio.
La dose sonore introduit deux composants, SoundDoseHelper
et SoundDoseManager,
, comme illustré à 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
- Conserver les valeurs de dose sonore
- Récupérer l'état en cas de plantage de
audioserver
- Déclencher des notifications de l'UI système
- Baisser le volume
SoundDoseManager
La classe SoundDoseManager
, qui se trouve dans le processus audioserver
et fait partie de la classe AudioFlinger
, collecte les données de dose sonore à partir de HAL ou les calcule en interne, en tant que solution de secours, à partir des frames envoyées à HAL. La classe SoundDoseManager
envoie les données de dose sonore à la classe SoundDoseHelper
.
MelProcessor et MelAggregator
Si la HAL ne peut pas fournir de valeurs MEL, les utilitaires MelProcessor
et MelAggregator
dans libaudioutils
sont utilisés pour le calcul interne de la dose sonore.
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. La nouvelle interface HAL permettant de récupérer les valeurs MEL calculées et d'émettre des avertissements d'exposition, nommée ISoundDose
, est donc définie dans le HAL audio AIDL. Toutefois, pour les implémenteurs qui ont besoin de plus de temps pour intégrer l'AIDL Audio HAL, nous avons un HAL AIDL de dose sonore 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 rappels 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 le reporting 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 AIDL autonome de la dose sonore
En attendant que les OEM puissent intégrer la dose sonore dans l'AIDL audio HAL, ils peuvent utiliser l'API AIDL autonome ISoundDoseFactory
comme solution de contournement. ISoundDoseFactory
utilise l'interface ISoundDose
, comme indiqué 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é avec le HAL audio AIDL pour la dose sonore
L'interface de dose sonore est prise en charge à long terme dans le cadre du HAL audio AIDL 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 les normes IEC62368-1 3e édition et EN50332-3. Par conséquent, il n'existe aucune API externe.
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 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 protection de l'audition 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 la réglementation sur la dose sonore est appliquée dans votre pays, vérifiez si
config_safe_media_volume_enabled
dansconfig.xml
est 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_enabled
dansconfig.xml
surtrue
. Pour les appareils compatibles avec le décodage par déchargement et qui n'implémentent pas les interfaces HAL de dose sonore,config_safe_sound_dosage_enabled
ne doit pas être défini surtrue
. Dans ce cas, définirconfig_safe_sound_dosage_enabled
surtrue
peut entraîner des valeurs CSD inexactes et des problèmes de certification pour les normes de protection de l'audition.
Le graphique de décision suivant décrit la logique qui détermine si les niveaux de sécurité auditive CSD ou les anciens niveaux (implémentés avant Android 14) sont calculés, en fonction des restrictions de pays et des valeurs des indicateurs.
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 IModule AIDL Audio HAL ou par VtsHalSoundDoseFactoryTargetTest
pour l'implémentation AIDL HAL de dose sonore autonome.