Dose di suoni

Android 14 supporta la dose di suoni nella framework audio e Audio HAL mediante il monitoraggio continuo delle misurazioni della dose sonora e avvisi sugli utenti circa livelli di esposizione dannosi.

Dose sonora è una misurazione dei livelli di pressione sonora in un determinato periodo di tempo. Monitorando la dose di suoni, possiamo contribuire a proteggere gli utenti dagli effetti dannosi della esposizione al suono eccessiva o prolungata, che offre una migliore protezione dell'udito quando si utilizzano le cuffie su dispositivi Android portatili e ridurre al minimo la possibilità di problemi di udito.

I nuovi standard per i dispositivi di ascolto sicuri sono conformi alle normative requisiti per la protezione dell'udito nella IEC62368-1 terza edizione (richiede l'accesso) ed EN50332-3 (accesso limitato agli abbonati), che introducono il concetto di dose sonora.

La funzionalità di dose del suono consente agli OEM di seguire le nuove normative in materia di sicurezza uditiva. A supportano una dose di suoni, gli OEM devono seguire le specifiche e le normative dell'interfaccia per tutte le personalizzazioni e le certificazioni. Un'implementazione OEM personalizzata può bypassare o modificare l'implementazione AOSP predefinita della dose sonora. Tuttavia, l'utilizzo dell'implementazione AOSP è vivamente consigliato.

Calcolo della dose sonora

Gli standard in IEC62368-1 3a edizione e EN50332-3 aumentano la precisione misurare l'esposizione al suono calcolando la dose sonora calcolata (CSD). CSD è vengono calcolati integrando i livelli di esposizione momentanea (MEL) nel tempo. Un periodo di 7 giorni la finestra a rotazione continua dei valori CSD accumulati viene mantenuta per il calcolo della dose audio.

In conformità con la sezione 10.6.3.2 della IEC62368-1 standard, se il valore CSD raggiunge il limite del 100%, il sistema avvisa l'utente dei livelli sonori a ogni aumento del 100%. Se l'utente non riconosce l'avviso, il volume si abbassa alla radiazione predefinita classe di energia 1 (RS1) valore della Tabella 39 della IEC62368-1.

Come menzionato nella sezione 10.6.3.3 della IEC62368-1 terza edizione, insieme alle indicazioni avvisi sulla dose, il sistema deve avviare un avviso basato sull'esposizione ogni volta Il valore MEL supera il valore della classe energetica della radiazione 2 (RS2) della Tabella 39 di IEC62368-1.

Per la certificazione ai sensi di queste normative e per valorizzare maggiormente i valori CSD pertinente, il sistema deve utilizzare valori di output precisi per quanto riguarda l'esperienza utente (come l'output di riproduzione multimediale). È importante che il calcolo CSD utilizza valori vicini ai livelli effettivi di pressione sonora a cui l'utente è esposto.

Architettura

A seconda di dove vengono acquisiti i fotogrammi, le caratteristiche e gli effetti dell'hardware dei trasduttori può influenzare il livello di potenza dei fotogrammi sottoposti a rendering. Per avere una misurazione precisa del livello di pressione sonora in uscita, abbiamo esteso l'HAL i valori MEL direttamente dall'hardware sottostante e tengono conto effetti applicati dal processore del segnale digitale (DSP) o dall'altoparlante come impedenza, sensibilità e risposta in frequenza.

Se l'HAL non può fornire valori MEL, come meccanismo di fallback, l'audio il framework analizza e calcola i CSD. Questo calcolo nel framework audio viene in base alle informazioni sull'output di cui è stato eseguito il rendering e riportato dall'HAL, inviate al DSP audio.

La funzionalità Sound Dose introduce due componenti, SoundDoseHelper e SoundDoseManager, come mostrato nella Figura 1:

Figura 1. Componenti architettonici della caratteristica della dose sonora.

SoundDoseHelper

La classe SoundDoseHelper, che si trova nel processo systemserver, è punto di raccolta principale per tutti i dati pertinenti sul dosaggio del suono. La AudioService gestisce la classe SoundDoseHelper.

Il corso SoundDoseHelper si occupa di quanto segue:

• Gestione delle nuove informazioni sul dosaggio
• Valori persistenti di dose sonora
• Recupero dello stato in caso di arresto anomalo di audioserver
• Attivazione delle notifiche UI di sistema
• Abbassare il volume

SoundDoseManager

La classe SoundDoseManager, che si trova nel processo audioserver ed è parte del AudioFlinger raccoglie i dati sulla dose sonora dall'HAL o li calcola internamente, come di riserva, dai frame inviati all'HAL. Il corso SoundDoseManager invia i dati della dose sonora nella classe SoundDoseHelper.

MelProcessor e MelAggregator

Se l'HAL non può fornire valori MEL, MelProcessor e MelAggregator. utilità in libaudioutils per il calcolo interno della dose sonora.

Nella classe MelProcessor, il calcolo principale viene eseguito su un buffer con campionamenti audio chiamando MelProcessor::process(const void* buffer, size_t bytes). Se necessario, gli OEM possono utilizzare MelProcessor nell'implementazione dell'HAL.

La classe MelAggregator riceve i valori MEL da diverse porte audio e Calcola il valore CSD con una finestra temporale continua di sette giorni. Il metodo MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) esegue la logica. I risultati vengono inviati alla classe SoundDoseManager per comunicazione con AudioService.

Implementazione

Le estensioni di interfaccia HIDL sono ritirate a partire da Android 14. quindi la nuova interfaccia HAL per il recupero dei valori MEL calcolati e l'emissione dell'esposizione denominato ISoundDose, fa parte dell'AIDL Audio HAL. Tuttavia, Per coloro che implementano l'infrastruttura che necessitano di più tempo per integrare AIDL Audio HAL, abbiamo una AIDL HAL, che offre la ISoundDoseFactory. Questo sarà verrà ritirata in futuro.

I metodi HAL per il supporto della dose sonora sono mostrati nel seguente codice esempio:

/**
 * 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 nuova interfaccia HAL implementa i callback che informano il framework sull'esposizione temporanea e forniscono valori MEL ogni volta che il livello di uscita supera RS1. Quando queste interfacce sono implementate, il framework li utilizza per i report CSD. Senza questa implementazione di callback, un'implementazione di riserva su AudioFlinger viene utilizzato per calcolare le stime dei valori CSD.

Nota: la disattivazione della decodifica audio compressa ottimizza l'utilizzo della batteria tramite lo streaming dati audio compressi direttamente sul DSP senza riattivare l'app host di fatturazione. In caso di decodifica dell'offload hardware, il framework ha accesso solo a dati audio compressi e non può stimare i valori MEL. In questa situazione, quando si utilizza l'implementazione della dose sonora AOSP, l'unico modo in cui un dispositivo può alle normative EN50332-3/IEC62368-1 consiste nel fornire valori MEL tramite dell'HAL.

Supporto AIDL autonomo per le dosi audio

Fino a quando gli OEM non saranno in grado di integrare la dose di suoni nell'AIDL audio HAL, possono usare come soluzione alternativa all'API AIDL autonoma ISoundDoseFactory. ISoundDoseFactory utilizza l'interfaccia ISoundDose, come mostrato in nell'esempio di codice riportato di seguito:

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

Supporto di AIDL Audio HAL per le dosi di suono

L'interfaccia della dose sonora è supportata a lungo termine come parte dell'AIDL Audio HAL da Estendere l'interfaccia di IModule, come mostrato nel seguente esempio di codice:

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

Questa funzione è un'implementazione di un nuovo regolamento descritto in IEC62368-1 ed EN50332-3, quindi non sono presenti API rivolte all'esterno.

Gli OEM possono certificare i propri dispositivi implementando le nuove interfacce HAL e fornire dati MEL accurati per CSD al framework audio (consigliato) oppure tramite offrendo un'implementazione personalizzata della dose audio.

Abilita il calcolo della dose sonora

Per impostazione predefinita, AOSP supporta la logica di sicurezza dell'udito che garantisce la certificazione agli standard EN50332-2 e IEC62368-1 10.6.5 esistenti.

In Android 14, il calcolo della dose sonora è disattivato per impostazione predefinita.

Attenzione: non attivare il calcolo della dose sonora per Android 14. La logica a supporto del calcolo del suono viene implementata SOLO a partire da Android 14-QPR1. Questa logica per l'abilitazione di CSD non è completamente funzionante su Android 14 e può causare imprecisioni nei dati CSD con i dispositivi Bluetooth.

Utilizza le seguenti linee guida per consentire il calcolo della dose sonora a partire da Android 14-QPR1.

• Se nel tuo paese sono in vigore le normative in materia di dose sonora, controlla se config_safe_media_volume_enabled a config.xml è impostato su true.

  Nota: nei paesi in cui le normative non sono applicate, gli OEM possono abilitare o disattivare CSD tramite SysUI, ad esempio un pulsante di attivazione/disattivazione nella pagina Impostazioni o un'app .

• Per essere conformi agli standard EN50332-3 e IEC62368-1 10.6.3, i fornitori devono il flag config_safe_sound_dosage_enabled in config.xml a true. Per i dispositivi che supportano la decodifica offload e non implementano interfacce HAL a dose sonora, config_safe_sound_dosage_enabled non deve essere impostato su true. In questi casi, l'impostazione di config_safe_sound_dosage_enabled su true può generare CSD impreciso ai valori e ai problemi di certificazione per gli standard di sicurezza dell'udito.

  Nota: gli OEM possono impostare il flag config_safe_sound_dose_enabled per specifiche per i paesi con l'override della bandiera frameworks/base/core/res/res/values-mcc${XX}/config.xml dove XX rappresenta il codice paese del paese (Centro clienti) del paese.

Il seguente grafico decisionale descrive la logica che determina se, in base a le restrizioni in base al paese e i valori delle segnalazioni, CSD o legacy livelli di sicurezza uditiva (implementati prima di Android 14) vengono calcolate.

Figura 2. Consente di calcolare la dose del suono (la logica viene aggiunta Android 14-QPR1).

Convalida

Quando implementano l'interfaccia HAL per la dose audio, gli OEM devono convalidare gli scenari di test VTS definiti da VtsHalAudioCoreTargetTest per l'implementazione dell'IModule AIDL Audio HAL oppure entro VtsHalSoundDoseFactoryTargetTest per l'implementazione indipendente della dose audio AIDL HAL.