Dosis de ruido

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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. Si supervisamos la dosis de sonido, podemos ayudar a proteger a los usuarios de los efectos dañinos de la exposición a sonidos excesivos o prolongados, lo que ofrece una mejor protección auditiva cuando se usan auriculares en dispositivos Android portátiles y minimiza las posibilidades de una discapacidad auditiva.

Los nuevos estándares para dispositivos de audio seguros cumplen con los requisitos reglamentarios de 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 sigan las nuevas reglamentaciones de seguridad auditiva. Para admitir la dosis de sonido, los OEMs 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 la 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). Para calcular el CSD, se integran los niveles de exposición momentáneos (MEL) a lo largo del tiempo. Un plan 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 conformidad con el artículo 10.6.3.2 de la norma IEC62368-1, 3ª edición, 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 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 de la 3ª edición de la norma 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 la MEL supere el valor de la fuente de energía de radiación de clase 2 (RS2) de la tabla 39 de la norma 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ñal digital (DSP) o la bocina como la impedancia, la sensibilidad y la frecuencia de respuesta.

Si el sistema 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 HAL y los fotogramas que se envían al 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

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 manejar la nueva información de dosificación
• Cómo conservar los valores de dosis de ruido
• Recuperación del estado en caso de una 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 es parte de la 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 la dosis de sonido a la clase SoundDoseHelper.

MelProcessor y MelAggregator

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

En la clase MelProcessor, el procesamiento principal se realiza en un búfer con muestras de audio mediante una llamada a MelProcessor::process(const void* buffer, size_t bytes). Los OEMs 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 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 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. Esto 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 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 las usa para generar 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.

Compatibilidad con AIDL independiente de dosis de ruido

Hasta que los OEMs 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 la HAL de audio de AIDL de dosis de ruido

La interfaz de dosis de sonido es compatible a largo plazo como parte de la HAL de audio de AIDL, ya que se extiende la interfaz IModule, como se muestra 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 OEMs pueden certificar sus dispositivos implementando las nuevas interfaces de HAL y proporcionando datos de MEL precisos para el CSD al framework de audio (recomendado) o proporcionando una implementación de dosis de sonido personalizada.

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 y IEC62368-1 10.6.5.

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

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.

• Para cumplir con 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 de HAL de dosis de sonido, config_safe_sound_dosage_enabled no se debe establecer en true. En esos casos, configurar 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.

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.