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 monitorear la dosis de ruido, podemos ayudar a proteger a los usuarios de los efectos dañinos de la 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 minimiza la posibilidad de una discapacidad auditiva.

Los nuevos estándares para dispositivos de escucha seguros cumplen con los requisitos reglamentarios para la protección auditiva en la IEC62368-1, 3ª edición (requiere acceso) y la EN50332-3 (acceso limitado a suscriptores), que introducen el concepto de dosis de sonido.

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

Cálculo de la dosis de ruido

Los estándares de la 3ª edición de IEC62368-1 y EN50332-3 aumentan la precisión de la medición de la exposición al sonido mediante el cálculo de la dosis de sonido calculada (CSD). El CSD se calcula integrando los niveles de exposición momentánea (MEL) a lo largo del tiempo. Se mantiene una ventana continua de siete días de valores de CSD acumulados para el cálculo de la dosis de sonido.

De acuerdo con el artículo 10.6.3.2 de la edición 3 de IEC62368-1, si el valor de CSD alcanza el límite del 100%, el sistema alerta al usuario sobre los niveles de sonido en cada aumento del 100%. Si el usuario no confirma la advertencia, el volumen se reduce al valor predefinido de la clase 1 de fuente de energía radiante (RS1) de la tabla 39 de IEC62368-1.

Como se menciona en la sección 10.6.3.3 de la edición 3 de IEC62368-1, junto con las advertencias de dosis de sonido, el sistema debe iniciar una advertencia basada en la exposición cada vez que el valor de MEL supere el valor de la clase 2 de fuente de energía de radiación (RS2) de la Tabla 39 de IEC62368-1.

Para obtener la certificación según estas reglamentaciones y hacer que los valores de CSD sean más pertinentes, el sistema debe usar valores de salida precisos tal como los perciben los usuarios (como la salida de reproducción de medios). Es importante que el cálculo del CSD use valores cercanos a los niveles de presión acústica reales a los que se expone el usuario.

Arquitectura

Según dónde se capturen los fotogramas, las características del hardware y los efectos de los transductores pueden influir en el nivel de potencia de los fotogramas renderizados. Para obtener una medición precisa del nivel de presión acústica de salida, extendimos la HAL para obtener los valores de MEL directamente del hardware subyacente y tener en cuenta los posibles efectos que aplican el procesador de señales digitales (DSP) o las propiedades de los altavoces, como la impedancia, la sensibilidad y la respuesta de frecuencia.

Si el HAL no puede proporcionar valores de MEL, como mecanismo de resguardo, el framework de audio analiza y calcula el CSD. Este cálculo en el framework de audio se basa en la información sobre la salida renderizada que informa el HAL y los fotogramas que se envían al DSP de audio.

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

sound_dose_arch

Figura 1: Componentes de la arquitectura de la función de dosis de sonido.

SoundDoseHelper

La clase SoundDoseHelper, que se encuentra en el proceso systemserver, es el punto de recopilación principal de todos los datos relevantes de dosificación de sonido. La clase AudioService administra la clase SoundDoseHelper.

La clase SoundDoseHelper es responsable de lo siguiente:

  • Cómo controlar la información de dosis nueva
  • Cómo conservar los valores de dosis de ruido
  • Estado de recuperación en caso de falla de audioserver
  • Cómo activar notificaciones de la IU del sistema
  • Bajar el volumen

SoundDoseManager

La clase SoundDoseManager, que se encuentra en el proceso audioserver y forma parte de la clase AudioFlinger, recopila los datos de dosis de sonido del HAL o los calcula de forma interna, como alternativa, a partir de los fotogramas enviados al HAL. La clase SoundDoseManager envía los datos de dosis de sonido a la clase SoundDoseHelper.

MelProcessor y MelAggregator

Si el HAL no puede proporcionar valores de MEL, se usan las utilidades MelProcessor y MelAggregator en libaudioutils para el cálculo interno de la dosis de sonido.

En la clase MelProcessor, el cálculo principal se realiza en un búfer con muestras de audio llamando a MelProcessor::process(const void* buffer, size_t bytes). Los OEM pueden usar MelProcessor en su 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 para la comunicación con AudioService.

Implementación

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

Los métodos de HAL para la compatibilidad con la dosis de sonido se muestran en el siguiente ejemplo de código:

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

Compatibilidad con AIDL independiente de dosis de ruido

Hasta que los OEM puedan integrar la dosis de sonido en el HAL de audio de AIDL, pueden usar la API de AIDL independiente 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 HAL de audio de AIDL de dosis de ruido

La interfaz de dosis de sonido se admite a largo plazo como parte de la HAL de audio de AIDL extendiendo la interfaz IModule, como se muestra en el siguiente ejemplo 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 una implementación de una nueva reglamentación que se describe en IEC62368-1, 3ª edición, y EN50332-3, por lo que no hay APIs externas.

Los OEM pueden certificar sus dispositivos implementando las nuevas interfaces HAL y proporcionando datos de MEL precisos para que CSD los envíe al framework de audio (recomendado) o proporcionando una implementación personalizada de la dosis de sonido.

Habilita el cálculo de la dosis de sonido

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

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

Sigue los lineamientos que se indican a continuación para habilitar el cálculo de la dosis de sonido a partir de Android 14-QPR1.

  • Si las reglamentaciones sobre dosis de sonido se aplican en tu país, verifica si config_safe_media_volume_enabled en config.xml está establecido en true.

  • Para cumplir con los requisitos de EN50332-3 y IEC62368-1 10.6.3, los proveedores deben superponer la marca config_safe_sound_dosage_enabled en config.xml a true. En el caso de los dispositivos que admiten la decodificación de descarga y no implementan las interfaces HAL de dosis de sonido, config_safe_sound_dosage_enabled no debe establecerse en true. En estos casos, establecer config_safe_sound_dosage_enabled en true puede generar valores de CSD imprecisos y problemas de certificación para los estándares de audición de seguridad.

En el siguiente gráfico de decisión, se describe la lógica que determina si, según las restricciones del país y los valores de las marcas, se calculan los niveles de seguridad auditiva del CSD o los heredados (implementados antes de Android 14).

enable_csd

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

Validación

Cuando implementan la interfaz de HAL para la dosis de sonido, los OEM deben validar los casos de prueba de VTS definidos por VtsHalAudioCoreTargetTest para la implementación de IModule AIDL Audio HAL o por VtsHalSoundDoseFactoryTargetTest para la implementación de HAL de AIDL de dosis de sonido independiente.