Dose sonora

O Android 14 oferece suporte para dose sonora no framework e na HAL de áudio monitorando continuamente medições de dose sonora e emitindo alertas para usuários sobre os níveis de exposição prejudiciais.

A dose sonora é uma medida dos níveis de pressão sonora durante um período. Ao monitorar a dose sonora, podemos ajudar a proteger os usuários dos efeitos prejudiciais das exposição excessiva ou prolongada ao som, oferecendo melhor proteção auditiva ao usar fones de ouvido em dispositivos Android portáteis e ao minimizar a chance de um deficiência auditiva.

Os novos padrões para dispositivos de áudio seguro estão em conformidade com as regulamentações requisitos de proteção auditiva na IEC62368-1 3a edição (requer login) e EN50332-3 (acesso limitado a assinantes), que introduz o conceito de dose sonora.

A função de dose sonora permite que OEMs sigam as novas regulamentações de segurança auditiva. Para oferecem suporte à dose sonora, os OEMs precisam seguir as especificações e as regulamentações da interface para todas as personalizações e certificações. Uma implementação personalizada de OEM pode ignorar ou modificar a implementação padrão de dose sonora do AOSP. No entanto, é altamente recomendado usar a implementação do AOSP.

Cálculo da dose sonora

As normas IEC62368-1 3a edição e EN50332-3 aumentam a precisão Medir a exposição sonora ao calcular a dose sonora calculada (CSD). CSD é computados pela integração de níveis de exposição momentânea (MEL, na sigla em inglês) ao longo do tempo. Um período de sete dias janela contínua de valores de CSD acumulados é mantida para o de dose sonora.

De acordo com a seção 10.6.3.2 da IEC62368-1 3a edição, se o valor de CSD alcançar o limite de 100%, o sistema alerta o usuário sobre os níveis sonoros em cada aumento de 100%. Se o usuário não confirmar o alerta, o volume vai diminuir para a radiação predefinida valor da classe de fonte de energia 1 (RS1) da Tabela 39 da IEC62368-1.

Conforme mencionado na seção 10.6.3.3 da norma IEC62368-1 3a edição, junto com a seção de áudio de dose, o sistema deve iniciar um alerta de exposição sempre que o O valor da MEL excede o valor da classe de fonte de energia de radiação 2 (RS2) da Tabela 39 de IEC62368-1.

Para fins de certificação com essas regulamentações e para tornar os valores de CSD mais relevante, o sistema deve usar valores de saída precisos conforme percebidos pelos usuários como a saída de reprodução de mídia. É importante que o cálculo do CSD use valores próximos dos níveis reais de pressão sonora aos quais o usuário fica exposto.

Arquitetura

Dependendo de onde os frames são capturados, as características e os efeitos de hardware dos transdutores pode influenciar o nível de potência dos frames renderizados. Ter uma medida precisa do nível de pressão sonora de saída, estendemos a HAL para obter os valores de MEL diretamente do hardware subjacente e consideram possíveis efeitos aplicados pelo processador de sinal digital (DSP) ou pelos alto-falantes como impedância, sensibilidade e resposta em frequência.

Se a HAL não puder fornecer valores MEL, como mecanismo substituto, o áudio que analisa e calcula a CSD. Essa computação no framework de áudio é com base nas informações sobre a saída renderizada relatada pela HAL e os frames que são enviadas à DSP de áudio.

A dose sonora introduz dois componentes, SoundDoseHelper e SoundDoseManager,, conforme mostrado na Figura 1:

Figura 1. Componentes de arquitetura do recurso de dose sonora.

AjudadoSOM

A classe SoundDoseHelper, localizada no processo systemserver, é a local de coleta principal de todos os dados relevantes de dosagem sonora. O AudioService gerencia a classe SoundDoseHelper.

A classe SoundDoseHelper é responsável pelo seguinte:

• Como gerenciar novas informações de dosagem
• Manter valores de dose sonora
• Como recuperar o estado em caso de falha do audioserver
• Como acionar notificações da interface do sistema
• Diminuindo o volume

SoundDoseManager

A classe SoundDoseManager, que reside no processo audioserver e é parte do AudioFlinger coleta os dados de dose sonora da HAL ou os calcula internamente, como um dos frames enviados à HAL. A classe SoundDoseManager envia os dados de dose sonora para a classe SoundDoseHelper.

MelProcessor e MelAggregator

Se a HAL não puder fornecer valores de MEL, MelProcessor e MelAggregator utilitários em libaudioutils são usados para o cálculo da dose sonora interna.

Na classe MelProcessor, a computação principal é realizada em um buffer com amostras de áudio chamando MelProcessor::process(const void* buffer, size_t bytes). Os OEMs podem usar MelProcessor na implementação da HAL, se necessário.

A classe MelAggregator recebe os valores de MEL de diferentes portas de áudio e calcula o valor da CSD com uma janela contínua de sete dias. O método MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) executa a lógica. Os resultados são enviados para a classe SoundDoseManager a comunicação com AudioService.

Implementação

As extensões de interface HIDL foram descontinuadas no Android 14 e versões mais recentes, a nova interface HAL para recuperar valores de MEL calculados e emitir exposição alertas, chamados ISoundDose, é definido como parte da HAL de áudio AIDL. No entanto, para implementadores que precisam de mais tempo para integrar a HAL de áudio AIDL, temos uma HAL de dose sonora independente AIDL, que oferece ISoundDoseFactory. Isso será descontinuada no futuro.

Os métodos da HAL para compatibilidade com a dose sonora são mostrados no código a seguir amostra:

/**
 * 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);
    }
}

A nova interface HAL implementa callbacks. que informam o framework sobre exposição momentânea e fornecem valores de MEL sempre que o nível de saída exceder RS1. Quando essas interfaces são implementadas, a estrutura usa esses dados para gerar relatórios de CSD. Sem essa implementação de callback, uma implementação substituta em AudioFlinger é usada para calcular estimativas de valores CSD.

Observação: o descarregamento da decodificação de áudio compactado otimiza o uso da bateria por streaming dados de áudio compactados diretamente para o DSP sem ativar o aplicativo host processamento. No caso dessa decodificação de descarga de hardware, o framework tem acesso apenas para dados de áudio compactados e não pode estimar valores de MEL. Nessa situação, ao usar a implementação de dose sonora do AOSP, a única maneira de um dispositivo cumprir às regulamentações EN50332-3/IEC62368-1 é fornecer valores MEL por meio do HAL.

Compatibilidade com AIDL independente de dose sonora

Até que os OEMs possam integrar a dose sonora à HAL de áudio AIDL, eles poderão usar o ISoundDoseFactory da API AIDL independente como solução alternativa. O ISoundDoseFactory usa a interface ISoundDose, conforme mostrado no exemplo de código a seguir:

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

Suporte à HAL de áudio AIDL de dose sonora

A interface de dose sonora é compatível com longo prazo como parte da HAL de áudio AIDL, estendendo a interface IModule, conforme mostrado neste exemplo 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();
}

Esse recurso é a implementação de uma nova regulamentação descrita na IEC62368-1 3a edição e EN50332-3. Portanto, não há APIs externas.

OEMs podem certificar seus dispositivos implementando as novas interfaces HAL e fornecendo dados de MEL precisos para CSD para a estrutura de áudio (recomendado), ou ao fornecer uma implementação de dose sonora personalizada.

Ativar o cálculo de dose sonora

Por padrão, o AOSP é compatível com a lógica de segurança auditiva que garante a certificação com as normas existentes EN50332-2 e IEC62368-1 10.6.5.

No Android 14, o cálculo de dose sonora é desativado por padrão.

Atenção: não ative o cálculo de dose sonora para o Android 14. A lógica para apoiar o cálculo de som dose é implementada SOMENTE a partir do Android 14-QPR1. Essa lógica para ativar a CSD não é totalmente funciona no Android 14 e pode causar imprecisões na CSD com dispositivos Bluetooth.

Use as seguintes diretrizes para ativar o cálculo de dose sonora a partir do Android 14 QPR1.

• Se os regulamentos de dose sonora forem em vigor no seu país, verifique se config_safe_media_volume_enabled em config.xml é definido como true.

  Observação: nos países em que as regulamentações não são aplicadas, os OEMs podem ativar ou desativar a CSD pela SysUI, como um botão na página Configurações ou um app; do Kubernetes.

• Para estar em conformidade com as normas EN50332-3 e IEC62368-1 10.6.3, os fornecedores precisam se sobrepor a sinalização config_safe_sound_dosage_enabled config.xml para true. Para dispositivos que oferecem suporte à decodificação de descarga e não implementam o interfaces HAL de dose sonora, O campo config_safe_sound_dosage_enabled não pode ser definido como true. Nesses casos, definir config_safe_sound_dosage_enabled como true pode gerar CSDs incorretas e problemas de certificação para padrões auditivos de segurança.

  Observação: OEMs podem definir a flag config_safe_sound_dose_enabled para em outros países, substituindo a sinalização frameworks/base/core/res/res/values-mcc${XX}/config.xml em que XX representa o código do país para dispositivos móveis (MCC).

O gráfico de decisões a seguir descreve a lógica que determina se, com base as restrições de país e os valores das sinalizações, a CSD ou as níveis de segurança auditiva (implementados antes do Android 14); são calculados.

Figura 2. Ativa o cálculo de dose sonora (a lógica é adicionada em QPR1 do Android 14).

Validação

Ao implementar a interface HAL para dose sonora, os OEMs precisam fazer a validação em relação os casos de teste VTS definidos por VtsHalAudioCoreTargetTest para a implementação da HAL de áudio AIDL do IModule ou VtsHalSoundDoseFactoryTargetTest para a implementação autônoma da HAL de dose sonora AIDL.