Schalldosis

Android 14 bietet Unterstützung für die Schalldosis im Audio-Framework und Audio HAL durch kontinuierliche Überwachung der Schalldosismessungen und Ausgabe von Warnungen an Benutzer vor schädlichen Expositionspegeln.

Die Schalldosis ist eine Messung des Schalldruckpegels über einen bestimmten Zeitraum. Durch die Überwachung der Schalldosis können wir dazu beitragen, Benutzer vor den schädlichen Auswirkungen übermäßiger oder längerer Schallbelastung zu schützen. So bieten wir einen besseren Gehörschutz bei der Verwendung von Kopfhörern auf tragbaren Android-Geräten und minimieren das Risiko einer Hörschädigung.

Die neuen Standards für sichere Abhörgeräte entsprechen den gesetzlichen Anforderungen für Gehörschutz in IEC62368-1 3. Ausgabe (Anmeldung erforderlich) und EN50332-3 (Zugriff auf Abonnenten beschränkt), die das Konzept der Schalldosis einführen.

Mit der Schalldosisfunktion können OEMs die neuen Gehörschutzvorschriften einhalten. Um eine Schalldosis zu unterstützen, müssen OEMs bei allen Anpassungen und Zertifizierungen Schnittstellenspezifikationen und -vorschriften befolgen. Eine angepasste OEM-Implementierung kann die AOSP-Standardimplementierung der Schalldosis umgehen oder ändern. Die Verwendung der AOSP-Implementierung wird jedoch dringend empfohlen.

Berechnung der Schalldosis

Die Normen IEC62368-1 3. Ausgabe und EN50332-3 erhöhen die Genauigkeit der Messung der Schallbelastung durch Berechnung der berechneten Schalldosis (CSD). CSD wird durch Integration der momentanen Expositionswerte (MEL) über die Zeit berechnet. Für die Berechnung der Schalldosis wird ein kontinuierlich siebentägiges Fenster der akkumulierten CSD-Werte beibehalten.

Gemäß Abschnitt 10.6.3.2 von IEC62368-1, 3. Ausgabe, warnt das System den Benutzer bei jedem Anstieg um 100 %, wenn der CSD-Wert den Grenzwert von 100 % erreicht. Wenn der Benutzer die Warnung nicht bestätigt, sinkt die Lautstärke auf den vordefinierten Wert der Strahlungsenergiequelle Klasse 1 (RS1) aus Tabelle 39 von IEC62368-1.

Wie in Abschnitt 10.6.3.3 von IEC62368-1 3. Ausgabe erwähnt, muss das System zusammen mit den Schalldosiswarnungen jedes Mal eine expositionsbasierte Warnung auslösen, wenn der MEL-Wert den Wert der Strahlungsenergiequelle Klasse 2 (RS2) aus Tabelle 39 von IEC62368 überschreitet -1.

Für die Zertifizierung nach diesen Vorschriften und um die CSD-Werte relevanter zu machen, muss das System genaue Ausgabewerte verwenden, wie sie von den Benutzern wahrgenommen werden (z. B. die Medienwiedergabeausgabe). Für die CSD-Berechnung ist es wichtig, Werte zu verwenden, die nahe am tatsächlichen Schalldruckpegel liegen, dem der Benutzer ausgesetzt ist.

Die Architektur

Je nachdem, wo die Frames erfasst werden, können Hardwareeigenschaften und Effekte der Wandler den Leistungspegel der gerenderten Frames beeinflussen. Um eine präzise Messung des Ausgangsschalldruckpegels zu ermöglichen, haben wir den HAL erweitert, um die MEL-Werte direkt von der zugrunde liegenden Hardware zu erhalten und mögliche Effekte zu berücksichtigen, die durch den digitalen Signalprozessor (DSP) oder Lautsprechereigenschaften wie Impedanz, Empfindlichkeit, und Frequenzgang.

Wenn die HAL keine MEL-Werte bereitstellen kann, analysiert und berechnet das Audio-Framework als Fallback-Mechanismus den CSD. Diese Berechnung im Audio-Framework basiert auf den von HAL gemeldeten Informationen über die gerenderte Ausgabe und auf Frames, die an den Audio-DSP gesendet werden.

Sound Dose führt zwei Komponenten ein, SoundDoseHelper und SoundDoseManager, wie in Abbildung 1 dargestellt:

sound_dose_arch

Abbildung 1. Architektonische Komponenten der Schalldosisfunktion.

SoundDoseHelper

Die SoundDoseHelper Klasse, die sich im systemserver Prozess befindet, ist der Hauptsammelpunkt für alle relevanten Schalldosierungsdaten. Die AudioService Klasse verwaltet die SoundDoseHelper Klasse.

Die SoundDoseHelper Klasse ist für Folgendes verantwortlich:

  • Umgang mit neuen Dosierungsinformationen
  • Anhaltende Schalldosiswerte
  • Wiederherstellung des Zustands im Falle eines audioserver Absturzes
  • Auslösen von System-UI-Benachrichtigungen
  • Lautstärke verringern

SoundDoseManager

Die SoundDoseManager Klasse, die sich im audioserver Prozess befindet und Teil der AudioFlinger Klasse ist, sammelt die Schalldosisdaten vom HAL oder berechnet sie intern als Fallback aus den an den HAL gesendeten Frames. Die SoundDoseManager Klasse sendet die Schalldosisdaten an die SoundDoseHelper Klasse.

MelProcessor und MelAggregator

Wenn der HAL keine MEL-Werte bereitstellen kann, werden die Dienstprogramme MelProcessor und MelAggregator in libaudioutils für die interne Schalldosisberechnung verwendet.

In der MelProcessor Klasse wird die Hauptberechnung für einen Puffer mit Audio-Samples durch den Aufruf MelProcessor::process(const void* buffer, size_t bytes) durchgeführt. OEMs können MelProcessor bei Bedarf in ihrer HAL-Implementierung verwenden.

Die MelAggregator Klasse empfängt die MEL-Werte von verschiedenen Audio-Ports und berechnet den CSD-Wert mit einem gleitenden Fenster von sieben Tagen. Die Methode MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) führt die Logik aus. Die Ergebnisse werden zur Kommunikation mit AudioService an die SoundDoseManager -Klasse gesendet.

Implementierung

HIDL-Schnittstellenerweiterungen sind ab Android 14 veraltet, daher ist die neue HAL-Schnittstelle zum Abrufen berechneter MEL-Werte und zum Ausgeben von Belichtungswarnungen mit dem Namen ISoundDose als Teil von AIDL Audio HAL definiert. Für Implementierer, die mehr Zeit für die Integration des AIDL Audio HAL benötigen, haben wir jedoch einen eigenständigen Sound Dose AIDL HAL , der die ISoundDoseFactory Schnittstelle bietet. Dies wird in Zukunft nicht mehr unterstützt.

Die HAL-Methoden zur Schalldosisunterstützung werden im folgenden Codebeispiel gezeigt:

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

Die neue HAL-Schnittstelle implementiert Rückrufe , die das Framework über die momentane Exposition informieren und MEL-Werte bereitstellen, wenn der Ausgangspegel RS1 überschreitet. Wenn diese Schnittstellen implementiert sind, verwendet das Framework sie für das CSD-Reporting. Ohne diese Callback-Implementierung wird eine Fallback-Implementierung auf AudioFlinger verwendet, um Schätzungen von CSD-Werten zu berechnen.

Standalone-AIDL-Unterstützung für Schalldosis

Bis OEMs die Schalldosis in die AIDL-Audio-HAL integrieren können, können sie die eigenständige AIDL-API ISoundDoseFactory als Problemumgehung verwenden. ISoundDoseFactory verwendet die ISoundDose Schnittstelle, wie im folgenden Codebeispiel gezeigt:

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

Schalldosis AIDL Audio HAL-Unterstützung

Die Sound Dose-Schnittstelle wird als Teil des AIDL Audio HAL langfristig unterstützt, indem die IModule Schnittstelle erweitert wird, wie im folgenden Codebeispiel gezeigt:

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

Bei dieser Funktion handelt es sich um eine Umsetzung einer neuen Regelung, die in IEC62368-1 3. Ausgabe und EN50332-3 beschrieben ist, sodass es keine nach außen gerichteten APIs gibt.

OEMs können ihre Geräte zertifizieren, indem sie die neuen HAL-Schnittstellen implementieren und dem Audio-Framework genaue MEL-Daten für CSD bereitstellen (empfohlen) oder indem sie eine benutzerdefinierte Implementierung der Schalldosis bereitstellen.

Aktivieren Sie die Berechnung der Schalldosis

Standardmäßig unterstützt AOSP die Gehörsicherheitslogik, die eine Zertifizierung mit den bestehenden Normen EN50332-2 und IEC62368-1 10.6.5 gewährleistet.

In Android 14 ist die Berechnung der Schalldosis standardmäßig deaktiviert.

Verwenden Sie die folgenden Richtlinien, um die Berechnung der Schalldosis ab Android 14-QPR1 zu ermöglichen.

  • Wenn in Ihrem Land Schalldosisvorschriften gelten, prüfen Sie, ob config_safe_media_volume_enabled in config.xml auf true gesetzt ist.

  • Um mit EN50332-3 und IEC62368-1 10.6.3 konform zu sein, müssen Anbieter das Flag config_safe_sound_dosage_enabled in config.xml auf true setzen. Für Geräte, die Offload-Dekodierung unterstützen und die Schalldosis-HAL-Schnittstellen nicht implementieren, darf config_safe_sound_dosage_enabled nicht auf true gesetzt sein. In solchen Fällen kann das Setzen config_safe_sound_dosage_enabled auf true zu ungenauen CSD-Werten und Zertifizierungsproblemen für Sicherheitsstandards für Gehör führen.

Das folgende Entscheidungsdiagramm beschreibt die Logik, die bestimmt, ob basierend auf den Länderbeschränkungen und den Werten der Flaggen entweder der CSD oder die alten Gehörschutzstufen (implementiert vor Android 14) berechnet werden.

enable_csd

Abbildung 2. Aktivieren Sie die Berechnung der Schalldosis (die Logik wird in Android 14-QPR1 hinzugefügt).

Validierung

Bei der Implementierung der HAL-Schnittstelle für die Schalldosis müssen OEMs anhand der VTS-Testfälle validieren, die von VtsHalAudioCoreTargetTest für die IModule AIDL Audio HAL-Implementierung oder von VtsHalSoundDoseFactoryTargetTest für die eigenständige Schalldosis-AIDL HAL-Implementierung definiert werden.