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. 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 de 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 del OEM puede omitir o modificar la implementación predeterminada de AOSP de la dosis de sonido. Sin embargo, se recomienda usar la implementación de AOSP.

Cálculo de la dosis de ruido

Los estándares de la IEC62368-1 3ª edición y la 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). Para calcular el CSD, se integran los niveles de exposición momentáneos (MEL) a lo largo del tiempo. Se mantiene un período continuo de siete días de valores de CSD acumulados para el cálculo de la dosis de sonido.

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 confirma la advertencia, el volumen se reduce al valor predefinido de la fuente de energía de radiación de clase 1 (RS1) de la tabla 39 de la norma 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 la certificación con estas reglamentaciones y hacer que los valores de CSD sean más relevantes, el sistema debe usar valores de salida precisos tal como los perciben los usuarios (como la salida de reproducción de contenido multimedia). Es importante que el cálculo de CSD use valores cercanos a los niveles de presión acústica reales a los que está expuesto el usuario.

Arquitectura

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

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 la HAL y los fotogramas que se envían al DSP de audio.

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

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 manejar la nueva información de dosificación
• 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 resguardo, a partir de las tramas que se envían al 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 para la 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 HAL implementa funciones de devolución de llamada que informan al framework sobre la exposición momentánea y proporcionan valores de MEL cada vez que el nivel de salida supera RS1. Cuando se implementan estas interfaces, el framework las usa para los informes de CSD. Sin esta implementación de devolución de llamada, se usa una implementación alternativa en AudioFlinger para calcular estimaciones de los valores de CSD.

Nota: La descarga de la decodificación de audio comprimido optimiza el uso de batería, ya que transmite datos de audio comprimidos directamente al DSP sin activar el procesador de la app anfitrión. En el caso de esa decodificación de transferencia de hardware, el framework solo tiene acceso a los datos de audio comprimidos y no puede estimar los valores de MEL. En esta situación, cuando se usa la implementación de dosis de sonido de AOSP, la única forma en que un dispositivo puede cumplir con las reglamentaciones EN50332-3/IEC62368-1 es proporcionando valores de MEL a través de la interfaz HAL.

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 una implementación de una nueva reglamentación que se describe en la 3ª edición de IEC62368-1 y EN50332-3, por lo que no hay APIs orientadas a externos.

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.

Habilita el cálculo de la dosis de sonido

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.

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

Usa los siguientes lineamientos para habilitar el cálculo de la dosis de sonido a partir de Android 14-QPR1.

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

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

• 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.

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

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

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

Validación

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