Dosis de ruido

Android 14 ofrece compatibilidad con dosis de ruido en el framework de audio y en la HAL de audio a través de un monitoreo continuo de mediciones de dosis de ruido y una emisión de advertencias a los usuarios acerca de niveles de exposición dañinos.

La dosis de sonido es una medición de los niveles de presión sonora durante un período. Al controlar la dosis de ruido, podemos ayudar a proteger a los usuarios de los efectos perjudiciales exposición excesiva o prolongada al sonido, lo que ofrece una mejor protección auditiva cuando se usan auriculares en dispositivos Android portátiles y se minimiza la posibilidad de una discapacidad auditiva.

Los nuevos estándares de dispositivos de escucha segura cumplen con la requisitos de protección auditiva según la norma IEC62368‐1 (3a edición) (requiere acceso) y EN50332-3 (acceso limitado a los suscriptores), que presenta el concepto de dosis de ruido.

La función de dosis de sonido permite a los OEM cumplir con las nuevas reglamentaciones de seguridad auditiva. Para admiten dosis de ruido, los OEM deben seguir las especificaciones y reglamentaciones de la interfaz para todas las personalizaciones y certificaciones. Una implementación personalizada de OEM puede omitir o modificar la implementación predeterminada de dosis de ruido en el AOSP. Sin embargo, se recomienda usar la implementación de AOSP.

Cálculo de dosis de ruido

Los estándares en IEC62368-1 3a edición y EN50332-3 aumentan la precisión de medir la exposición al sonido mediante el cálculo de la dosis de ruido calculada (CSD). La CSD es calculada integrando los niveles de exposición momentánea (MEL) a lo largo del tiempo. Un enfoque de siete días La ventana móvil continua de valores de CSD acumulados se mantiene durante en el cálculo de dosis de ruido.

De acuerdo con el artículo 10.6.3.2 del estándar IEC62368-1 si el valor del CSD alcanza el límite del 100%, el sistema alerta al usuario sobre los niveles de sonido en cada aumento de 100%. Si el usuario no reconoce la advertencia, el volumen baja a la radiación predefinida valor de clase de fuente de energía 1 (RS1) de la tabla 39 del estándar IEC62368-1.

Como se menciona en el artículo 10.6.3.3 del estándar IEC62368-1 3a edición, junto con el advertencias sobre dosis, el sistema debe iniciar una advertencia cada vez que El valor de MEL supera el valor de clase 2 (RS2) de la fuente de energía de radiación de la tabla 39 de IEC62368-1

Para obtener una certificación con estas reglamentaciones y hacer que los valores de CSD sean más relevante, el sistema debe usar valores de salida exactos, tal como los perciben los usuarios (como la salida de reproducción de contenido multimedia). Es importante que el cálculo de la CSD use valores cercanos a los niveles reales de presión de sonido a los que el usuario si se expone.

Arquitectura

Las características y los efectos del hardware dependerán de dónde se capturen los fotogramas de los transductores puede influir en el nivel de potencia de los fotogramas renderizados. Para tener una medición precisa del nivel de presión del sonido de salida, extendimos la HAL para obtener los valores de la MEL directamente desde el hardware subyacente y explican efectos que aplica el procesador de señales digitales (DSP) o la bocina como la impedancia, la sensibilidad y la frecuencia de respuesta.

Si la HAL no puede proporcionar valores de MEL, como mecanismo de resguardo, el audio framework analiza y calcula la CSD. Este cálculo en el framework de audio se según la información sobre los resultados renderizados informados por la HAL y los fotogramas que se envían a la DSP de audio.

La dosis de ruido incluye dos componentes, SoundDoseHelper y SoundDoseManager,, como se muestra en la Figura 1:

Figura 1: Componentes arquitectónicos de la función de dosis de ruido

Ayuda de SoundDose

La clase SoundDoseHelper, que se encuentra en el proceso systemserver, es la punto de recolección principal para todos los datos relevantes sobre la dosis de ruido. La AudioService administra la clase SoundDoseHelper.

La clase SoundDoseHelper es responsable de lo siguiente:

• Manejo de la información sobre nuevas dosis
• Valores de dosis de ruido persistentes
• Recuperación del estado en caso de una falla de audioserver
• Cómo activar notificaciones de la IU del sistema
• Bajando el volumen

SoundDoseManager

La clase SoundDoseManager, que se encuentra en el proceso audioserver y es parte de AudioFlinger recopila los datos de dosis de ruido del HAL o los procesa internamente, resguardo de los fotogramas enviados a la HAL. La clase SoundDoseManager envía los datos de dosis de ruido a la clase SoundDoseHelper.

MelProcessor y MelAggregator

Si la HAL no puede proporcionar valores de MEL, el valor de MelProcessor y MelAggregator utilidades en libaudioutils se usan para calcular la dosis interna de ruido.

En la clase MelProcessor, el cálculo principal se realiza en un búfer con llamadas a MelProcessor::process(const void* buffer, size_t bytes) para mostrar muestras de audio. Los OEMs pueden usar MelProcessor en la implementación de HAL si es necesario.

La clase MelAggregator recibe los valores de MEL de diferentes puertos de audio y calcula el valor de CSD con una ventana móvil de siete días. El método MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) ejecuta la lógica. Los resultados se envían a la clase SoundDoseManager de comunicación con AudioService.

Implementación

Las extensiones de interfaz HIDL dejaron de estar disponibles a partir de Android 14 por lo que la nueva interfaz de HAL para recuperar valores de MEL calculados y emitir exposiciones advertencias, denominadas ISoundDose, se define como parte de la HAL de audio del AIDL. Sin embargo, para los implementadores que necesitan más tiempo para integrar la HAL de audio del AIDL, tenemos una sonido independiente HAL de AIDL, que ofrece la ISoundDoseFactory. Esto será dejará de estar disponible en el futuro.

Los métodos de HAL para admitir dosis de ruido se muestran en el siguiente código muestra:

/**
 * 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 nueva interfaz de la HAL implementa devoluciones de llamada. que informan al framework sobre la exposición momentánea y proporcionan valores de MEL cuando el nivel de salida supera RS1. Cuando se implementan estas interfaces, el framework los usa para los informes de CSD. Sin esta implementación de devolución de llamada, una implementación de resguardo en AudioFlinger se utiliza para calcular estimaciones de los valores de CSD.

Nota: La transferencia de la decodificación de audio comprimido optimiza el uso de batería mediante la transmisión datos de audio comprimidos directamente a la DSP sin activar la app host y un encargado del tratamiento de datos. En caso de esta decodificación de descarga de hardware, el framework tiene acceso solo a datos de audio comprimidos y no se pueden estimar los valores de MEL. En esta situación, cuando se usa la implementación de dosis de ruido del AOSP, la única forma en que un dispositivo puede cumplir las reglamentaciones EN50332-3/IEC62368-1 es proporcionar los valores de MEL a través de la Interfaz de HAL

Compatibilidad con AIDL independiente de dosis de ruido

Hasta que los OEMs puedan integrar la dosis de sonido en la HAL de audio del AIDL, pueden usar la API independiente de AIDL ISoundDoseFactory como solución alternativa. ISoundDoseFactory usa la interfaz ISoundDose, como se muestra en la siguiente muestra de código:

@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);
}

Compatibilidad con la HAL de audio del AIDL de dosis de ruido

La interfaz de dosis de sonido es compatible a largo plazo como parte de la HAL de audio del AIDL Se extiende la interfaz IModule, como se indica en la siguiente muestra de código:

@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();
}

Esta función es la implementación de una nueva reglamentación descrita en el estándar IEC62368-1. 3a edición y EN50332-3, por lo que no hay APIs externas.

Los OEM pueden certificar sus dispositivos implementando las nuevas interfaces de HAL y proporcionar datos de MEL precisos para CSD al framework de audio (recomendado) o con una implementación personalizada de una dosis de ruido.

Habilitar el cálculo de la dosis de ruido

De forma predeterminada, AOSP admite la lógica de seguridad auditiva que garantiza la certificación. con los estándares existentes EN50332-2 e IEC62368-1 10.6.5.

En Android 14, el cálculo de la dosis de ruido está inhabilitado de forma predeterminada.

Precaución: No habilites el cálculo de la dosis de ruido para el dispositivo Android 14. La lógica para admitir el cálculo del sonido dosis se implementa SOLO a partir de Android 14-QPR1. Esta lógica para habilitar la CSD no está completamente funciona en Android 14 y puede causar errores de CSD con dispositivos Bluetooth.

Sigue estos lineamientos para habilitar el cálculo de la dosis de ruido a partir de Android 14-QPR1.

• Si en tu país se aplican de manera forzosa las regulaciones sobre dosis de ruido, verifica si config_safe_media_volume_enabled en config.xml se establece en true.

  Nota: En los países donde no se aplican las reglamentaciones, los OEM pueden habilitar o inhabilitar la CSD a través de SysUI, como un botón de activación en la página Configuración, o una app del parámetro de configuración.

• Para cumplir con las normas EN50332-3 e IEC62368-1 10.6.3, los proveedores deben superponer la marca config_safe_sound_dosage_enabled en config.xml a true. Para los dispositivos que admiten la decodificación de descarga y no implementan el interfaces de HAL de dosis de sonido config_safe_sound_dosage_enabled no debe establecerse en true. En esos casos, Establecer config_safe_sound_dosage_enabled en true puede generar una CSD incorrecta. valores y problemas de certificación de los estándares de seguridad auditiva.

  Nota: Los OEMs pueden configurar la marca config_safe_sound_dose_enabled para solicitudes países anulando la bandera en frameworks/base/core/res/res/values-mcc${XX}/config.xml donde XX representa el código móvil de país (MCC) del país.

El siguiente gráfico de decisión describe la lógica que determina si, en función de las restricciones de país y los valores de las marcas, ya sea la CSD o la heredada niveles de seguridad auditiva (implementados antes de Android 14) calcular.

Figura 2: Habilita el cálculo de dosis de ruido (la lógica se agrega en Android 14-QPR1).

Validación

Cuando se implementa la interfaz HAL para dosis de ruido, los OEM deben validar los casos de prueba de VTS definidos por VtsHalAudioCoreTargetTest para la implementación de la HAL de audio del AIDL de IModule o de VtsHalSoundDoseFactoryTargetTest para la implementación independiente de la HAL del AIDL de dosis de ruido.