Dose di suoni

Android 14 supporta la dose sonora nel framework audio e nell'HAL audio monitorando continuamente le misurazioni della dose sonora e inviando avvisi agli utenti sui livelli di esposizione dannosi.

La dose sonora è una misurazione dei livelli di pressione sonora in un determinato periodo di tempo. Monitorando la dose sonora, possiamo contribuire a proteggere gli utenti dagli effetti dannosi dell'esposizione a suoni eccessivi o prolungati, offrendo così una migliore protezione dell'udito quando si utilizzano cuffie su dispositivi Android portatili e riducendo al minimo la possibilità di un calo uditivo.

I nuovi standard per i dispositivi di ascolto sicuro sono conformi ai requisiti previsti dalle normative per la protezione dell'udito riportati nella IEC62368-1 3rd edition (richiede l'accesso) e nella EN50332-3 (accesso limitato agli abbonati), che introducono il concetto di dose sonora.

La funzione di dose sonora consente agli OEM di rispettare le nuove normative sulla sicurezza uditiva. Per supportare la dose sonora, gli OEM devono rispettare le normative e le specifiche di interfaccia per tutte le personalizzazioni e le certificazioni. Un'implementazione OEM personalizzata può bypassare o modificare l'implementazione predefinita della dose sonora di AOSP. Tuttavia, consigliamo vivamente di utilizzare l'implementazione AOSP.

Calcolo della dose sonora

Gli standard IEC62368-1 3a edizione ed EN50332-3 aumentano l'accuratezza della misurazione dell'esposizione al suono calcolando la dose sonora calcolata (CSD). Il CSD viene calcolato integrando i livelli di esposizione momentanei (MEL) nel tempo. Per il calcolo della dose sonora viene mantenuta una finestra mobile continua di sette giorni dei valori CSD accumulati.

In conformità con la sezione 10.6.3.2 della norma IEC62368-1, 3a edizione, se il valore CSD raggiunge il limite del 100%, il sistema avverte l'utente circa i livelli di suono a ogni aumento del 100%. Se l'utente non conferma l'avviso, il volume si abbassa al valore predefinito della classe 1 (RS1) della fonte di energia radiante della Tabella 39 della norma IEC62368-1.

Come indicato nella sezione 10.6.3.3 della terza edizione della norma IEC62368-1, oltre agli avvisi relativi alla dose di suono, il sistema deve avviare un avviso basato sull'esposizione ogni volta che il valore MEL supera il valore della sorgente di energia radiante di classe 2 (RS2) della Tabella 39 della norma IEC62368-1.

Per la certificazione ai sensi di queste normative e per rendere più pertinenti i valori CSD, il sistema deve utilizzare valori di output accurati, come percepiti dagli utenti (ad esempio l'output di riproduzione dei contenuti multimediali). È importante che il calcolo del CSD utilizzi valori vicini ai livelli di pressione sonora effettivi a cui è esposto l'utente.

Architettura

A seconda di dove vengono acquisiti, le caratteristiche hardware e gli effetti dei trasduttori possono influire sul livello di potenza dei frame visualizzati. Per avere una misurazione precisa del livello di pressione sonora in uscita, abbiamo esteso l'HAL per ottenere i valori MEL direttamente dall'hardware sottostante e tenere conto dei possibili effetti applicati dall'elaborazione del segnale digitale (DSP) o dalle proprietà dello speaker, come impedenza, sensibilità e risposta in frequenza.

Se l'HAL non è in grado di fornire valori MEL, come meccanismo di riserva, il framework audio analizza e calcola il CSD. Questo calcolo nel framework audio si basa sulle informazioni sull'output visualizzato segnalato dall'HAL e sui frame inviati al DSP audio.

La dose sonora introduce due componenti, SoundDoseHelper e SoundDoseManager,, come mostrato nella Figura 1:

Figura 1. Componenti dell'architettura della funzionalità Dose sonora.

SoundDoseHelper

La classe SoundDoseHelper, che si trova nel processo systemserver, è il punto di raccolta principale per tutti i dati pertinenti relativi alla somministrazione di audio. Il corso AudioService gestisce il corso SoundDoseHelper.

La classe SoundDoseHelper è responsabile di quanto segue:

• Gestione delle nuove informazioni sulla posologia
• Valori della dose sonora permanenti
• Stato di recupero in caso di arresto anomalo di audioserver
• Attivazione delle notifiche dell'interfaccia utente di sistema
• Abbassare il volume

SoundDoseManager

La classe SoundDoseManager, che fa parte del processo audioserver e appartiene alla classe AudioFlinger, raccoglie i dati sulla dose sonora dall'HAL o li calcola internamente, come alternativa, dai frame inviati all'HAL. La classe SoundDoseManager invia i dati sulla dose sonora alla classe SoundDoseHelper.

MelProcessor e MelAggregator

Se l'HAL non è in grado di fornire valori MEL, gli strumenti MelProcessor e MelAggregator in libaudioutils vengono utilizzati per il calcolo della dose sonora interna.

Nella classe MelProcessor, il calcolo principale viene eseguito su un buffer con campioni 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 mobile di sette giorni. Il metodo MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) esegue la logica. I risultati vengono inviati alla classe SoundDoseManager per la comunicazione con AudioService.

Implementazione

Le estensioni dell'interfaccia HIDL sono ritirate a partire da Android 14, quindi la nuova interfaccia HAL per il recupero dei valori MEL calcolati e l'emissione di avvisi di esposizione, denominata ISoundDose, è definita nell'ambito dell'AIDL Audio HAL. Tuttavia, per gli implementatori che hanno bisogno di più tempo per integrare l'HAL Audio AIDL, è disponibile un HAL AIDL dose audio autonomo che offre l'interfaccia ISoundDoseFactory. Questo valore verrà ritirato in futuro.

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

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

Nota: lo sgravamento della decodifica audio compressa ottimizza l'utilizzo della batteria tramite lo streaming dei dati audio compressi direttamente al DSP senza riattivare l'elaboratore dell'app host. In caso di decodifica di offload hardware, il framework ha accesso solo ai 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ò essere conforme ai regolamenti EN50332-3/IEC62368-1 è fornire valori MEL tramite l'interfaccia HAL.

Supporto AIDL autonomo per la dose sonora

Fino a quando gli OEM non potranno integrare la dose sonora nell'HAL audio AIDL, possono utilizzare l'API AIDL autonoma ISoundDoseFactory come soluzione alternativa. ISoundDoseFactory utilizza l'interfaccia ISoundDose, come mostrato nell'esempio di codice seguente:

@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 HAL Audio AIDL per la dose sonora

L'interfaccia dose sonora è supportata a lungo termine nell'ambito dell'HAL Audio AIDL estendendo l'interfaccia 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 funzionalità è un'implementazione di un nuovo regolamento descritto nella norma IEC62368-1 3a edizione e EN50332-3, pertanto non sono presenti API rivolte all'esterno.

Gli OEM possono certificare i propri dispositivi implementando le nuove interfacce HAL e fornendo al framework audio dati MEL accurati per CSD (opzione consigliata) oppure fornendo un'implementazione personalizzata della dose sonora.

Attivare il calcolo della dose sonora

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

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

Attenzione: non attivare il calcolo della dose sonora per la release di Android 14. La logica per supportare il calcolo della dose di suono è implementata SOLO a partire da Android 14-QPR1. Questa logica per l'attivazione del CSD non è completamente funzionale su Android 14 e può causare imprecisioni del CSD con i dispositivi Bluetooth.

Segui le linee guida riportate di seguito per attivare il calcolo della dose sonora a partire da Android 14-QPR1.

• Se nel tuo paese sono in vigore normative sulla dose di suono, controlla se config_safe_media_volume_enabled in config.xml è impostato su true.

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

• Per essere conformi alle norme EN50332-3 e IEC62368-1 10.6.3, i fornitori devono sovrapporre il flag config_safe_sound_dosage_enabled in config.xml a true. Per i dispositivi che supportano la decodifica offload e non implementano le interfacce HAL per la dose sonora, config_safe_sound_dosage_enabled non deve essere impostato su true. In questi casi, impostare config_safe_sound_dosage_enabled su true può portare a valori CSD imprecisi e problemi di certificazione per gli standard di ascolto di sicurezza.

  Nota: gli OEM possono impostare il flag config_safe_sound_dose_enabled per paesi specifici eseguendo l'override del flag in frameworks/base/core/res/res/values-mcc${XX}/config.xml, dove XX rappresenta il codice paese mobile (MCC) del paese.

Il seguente grafo di decisione descrive la logica che determina se, in base alle limitazioni del paese e ai valori degli indicatori, vengono calcolati i livelli di sicurezza uditiva CSD o precedenti (implementati prima di Android 14).

Figura 2. Attiva il calcolo della dose sonora (la logica viene aggiunta in Android 14-QPR1).

Convalida

Quando implementano l'interfaccia HAL per la dose sonora, gli OEM devono eseguire la convalida in base ai casi di test VTS definiti da VtsHalAudioCoreTargetTest per l'implementazione dell'HAL Audio AIDL di IModule o da VtsHalSoundDoseFactoryTargetTest per l'implementazione dell'HAL AIDL della dose sonora autonoma.