Klangdosis

Android 14 unterstützt die Sounddosis in der Audio-Framework und Audio HAL durch kontinuierliche Überwachung der Schalldosismessungen Außerdem werden Nutzer vor schädlichen Schallbelastungen gewarnt.

Die Schalldosis ist eine Messung der Schalldruckpegel über einen bestimmten Zeitraum. Durch die Überwachung der Schallbelastung können wir zum Schutz der Nutzer vor den schädlichen Auswirkungen von übermäßiger oder längerer Schallbelastung, sodass ein besserer Gehörschutz gewährleistet ist wenn Sie Kopfhörer auf tragbaren Android-Geräten verwenden und die Wahrscheinlichkeit, Beeinträchtigung des Hörvermögens.

Die neuen Standards für sichere Hörgeräte entsprechen den behördlichen Anforderungen für den Gehörschutz nach IEC62368-1 (3. Edition) (Anmeldung erforderlich) und EN50332-3 (Zugriff nur für Abonnenten möglich), in denen das Konzept der Klangdosis vorgestellt wird.

Mit der Schalldosisfunktion können OEMs die neuen Vorschriften zur Hörsicherheit einhalten. Bis unterstützen die Sound Dosis, OEMs müssen Schnittstellenspezifikationen und Vorschriften einhalten für alle Anpassungen und Zertifizierungen. Eine benutzerdefinierte OEM-Implementierung kann die AOSP-Standardimplementierung der Tondosis umgehen oder ändern. Sie können jedoch Die Verwendung der AOSP-Implementierung wird dringend empfohlen.

Berechnung der Schalldosis

Die Normen in IEC62368-1 (3. Ausgabe) und EN50332-3 erhöhen die Genauigkeit von zum Messen der Schallbelastung, indem die berechnete Schalldosis (CSD) berechnet wird. CSD ist berechnet durch Integration der momentanen Expositionsbelastung (MEL) über die Zeit. Eine 7-Tage-Frist das fortlaufend gleitende Fenster der akkumulierten CSD-Werte Berechnung der Schalldosis.

Gemäß Abschnitt 10.6.3.2 von IEC62368-1 3. Wenn der CSD-Wert die Grenze von 100% erreicht, wird das System vom System informiert den Nutzer bei jeder Erhöhung um 100 % über den Geräuschpegel. Wenn der Nutzer die Warnung nicht bestätigt, wird die Lautstärke auf die vordefinierte Strahlung gesenkt. RS1-Wert (Energy Source Class 1) der Tabelle 39 von IEC62368-1.

Wie in Abschnitt 10.6.3.3 der 3. Ausgabe von IEC62368-1 erwähnt, zusammen mit der Warnungen bezüglich einer Dosis muss das System jedes Mal, wenn das System eine COVID-19-Warnung MEL-Wert überschreitet den Wert der Strahlungsenergiequellenklasse 2 (RS2) aus Tabelle 39 von IEC62368-1.

Zur Zertifizierung gemäß diesen Vorschriften und zur Verbesserung der CSD-Werte relevant ist, muss das System genaue Ausgabewerte verwenden, wie sie von den Nutzern wahrgenommen werden. (z. B. die Ausgabe der Medienwiedergabe). Es ist wichtig, dass die CSD-Berechnung sollten Werte verwendet werden, die dem tatsächlichen Schalldruckpegel entsprechen, exponiert ist.

Architektur

Je nachdem, wo die Frames aufgenommen werden, Hardwareeigenschaften und -effekte der Transducer können den Leistungspegel der gerenderten Frames beeinflussen. Muss eine präzise Messung des Schalldruckpegels ermöglicht, haben wir den HAL erweitert, der MEL-Werte direkt von der zugrunde liegenden Hardware abrufen und mögliche Effekte, die vom digitalen Signalprozessor (DSP) oder Lautsprecher angewendet werden Eigenschaften wie Impedanz, Empfindlichkeit und Frequenzgang.

Wenn der HAL keine MEL-Werte bereitstellen kann, wird das Audio analysiert und berechnet. Diese Berechnung im Audio-Framework ist basierend auf den Informationen über die gerenderte Ausgabe, die von HAL gemeldet wurde, und Frames die an die Audio-DSP gesendet werden.

Die Klangdosis beinhaltet zwei Komponenten: SoundDoseHelper und SoundDoseManager,, wie in Abbildung 1 gezeigt:

Abbildung 1: Architektonische Komponenten der Schalldosisfunktion.

SoundDoseHelper

Die Klasse SoundDoseHelper, die sich im systemserver-Prozess befindet, ist die zentrale Sammelstelle für alle relevanten Schalldosierdaten. Die AudioService class verwaltet die SoundDoseHelper-Klasse.

Die Klasse SoundDoseHelper ist für Folgendes verantwortlich:

• Umgang mit neuen Dosierungsinformationen
• Anhaltende Schalldosiswerte
• Status wird bei audioserver Absturz wiederhergestellt
• System-UI-Benachrichtigungen auslösen
• Lautstärke verringern

SoundDoseManager

Die Klasse SoundDoseManager, die sich im audioserver-Prozess befindet und Teil der AudioFlinger erfasst die Schalldosisdaten aus dem HAL oder berechnet sie intern als aus den an den HAL gesendeten Frames. Die Klasse SoundDoseManager sendet die Daten zur Schalldosis an die Klasse SoundDoseHelper.

MelProcessor und MelAggregator

Wenn der HAL keine MEL-Werte bereitstellen kann, werden MelProcessor und MelAggregator Dienstprogramme in libaudioutils werden zur Berechnung der internen Schalldosis verwendet.

In der MelProcessor-Klasse wird die Hauptberechnung in einem Zwischenspeicher mit durch Aufrufen von MelProcessor::process(const void* buffer, size_t bytes). OEMs können bei Bedarf MelProcessor in ihrer HAL-Implementierung verwenden.

Die Klasse MelAggregator empfängt die MEL-Werte von verschiedenen Audioports und berechnet den CSD-Wert mit einem rollierenden Zeitfenster von sieben Tagen. Die Methode MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) die Logik ausführt. Die Ergebnisse werden an die Klasse SoundDoseManager gesendet für Kommunikation mit AudioService.

Implementierung

HIDL-Benutzeroberflächenerweiterungen werden ab Android 14 eingestellt. sodass die neue HAL-Schnittstelle zum Abrufen der berechneten MEL-Werte Warnungen mit dem Namen ISoundDose ist als Teil des AIDL Audio HAL definiert. Sie können jedoch Für Implementierer, die mehr Zeit für die Integration des AIDL Audio HAL benötigen, gibt es eine eigenständigen Sound Dosis AIDL HAL bietet, ISoundDoseFactory-Oberfläche. Dies ist in Zukunft eingestellt werden.

Die HAL-Methoden zur Unterstützung der Schalldosis sind im folgenden Code dargestellt: Beispiel:

/**
 * 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 Callbacks. die als Grundlage für eine kurzfristige Exposition dienen und MEL-Werte liefern. wenn der Ausgabepegel RS1 überschreitet. Wenn diese Schnittstellen implementiert sind, werden sie für die Berichterstellung für benutzerdefinierte Darstellungen verwendet. Ohne diese Callback-Implementierung eine Fallback-Implementierung für AudioFlinger wird verwendet, um Schätzungen für CSD-Werte zu berechnen.

Hinweis :Durch das Auslagern der komprimierten Audiodecodierung wird die Akkunutzung durch Streaming optimiert. komprimierte Audiodaten direkt auf der DSP, ohne die Host-App zu aktivieren. Prozessor. Im Falle einer solchen Hardwareauslagerungsdecodierung hat das Framework Zugriff nur auf komprimierte Audiodaten und kann keine MEL-Werte schätzen. In dieser Situation bei Verwendung der AOSP-Tondosis-Implementierung EN50332-3/IEC62368-1 durch die Bereitstellung von MEL-Werten über die HAL-Schnittstelle.

Eigenständige AIDL-Unterstützung für Sounddose

Bis OEMs die Sounddosis in den AIDL Audio HAL integrieren können, können sie die eigenständige AIDL API ISoundDoseFactory als Behelfslösung. ISoundDoseFactory verwendet die ISoundDose-Oberfläche, wie in den folgenden Codebeispiel:

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

Unterstützung von AIDL Audio HAL zur Klangdosis

Die Audiodosis-Schnittstelle wird langfristig als Teil des AIDL Audio HAL unterstützt durch Erweitern der IModule-Schnittstelle, 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();
}

Diese Funktion ist eine Implementierung einer neuen Vorschrift, die in IEC62368-1 beschrieben wird. und EN50332-3, sodass es keine nach außen gerichteten APIs gibt.

OEMs können ihre Geräte zertifizieren, indem sie die neuen HAL-Schnittstellen implementieren und Bereitstellung korrekter MEL-Daten für CSD für das Audio-Framework (empfohlen) oder durch und eine individuelle Implementierung von Schalldämpfen.

Berechnung der Schalldosis aktivieren

Standardmäßig unterstützt AOSP die Logik für den Hörschutz, die die Zertifizierung mit den bestehenden Normen EN50332-2 und IEC62368-1 10.6.5.

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

Achtung :Aktivieren Sie die Berechnung der Schalldosis nicht für die Android-App Version 14. Logik zur Unterstützung der Berechnung von Geräuschen Die Dosis wird erst mit Android implementiert. 14-QPR1. Die Logik zum Aktivieren des CSD ist nicht vollständig unter Android 14 funktioniert und zu CSD-Ungenauigkeiten führen kann, mit Bluetooth-Geräten.

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

• Wenn in deinem Land Vorschriften zur Schalldosierung gelten, prüfe, ob config_safe_media_volume_enabled in config.xml ist auf true eingestellt.

  Hinweis: In Ländern, in denen die Vorschriften nicht durchgesetzt werden, können OEMs CSD über die SysUI deaktivieren (z. B. über eine Ein/Aus-Schaltfläche auf der Seite Einstellungen) oder über eine App Einstellung.

• Zur Einhaltung von EN50332-3 und IEC62368-1 10.6.3 müssen Anbieter die das Flag config_safe_sound_dosage_enabled in config.xml an true. Für Geräte, die die Auslagerungs-Decodierung unterstützen und die HAL-Schnittstellen zur Schalldosis config_safe_sound_dosage_enabled darf nicht auf true festgelegt sein. In solchen Fällen Das Festlegen von config_safe_sound_dosage_enabled auf true kann zu ungenauen CSDs führen Werten und Zertifizierungsfragen für Standards zum Schutz vor Hörvermögen.

  Hinweis: OEMs können das Flag config_safe_sound_dose_enabled für bestimmte indem Sie die Flagge in frameworks/base/core/res/res/values-mcc${XX}/config.xml Dabei steht XX für den Mobile Country Code (MCC) des Landes.

Die folgende Entscheidungsgrafik beschreibt die Logik, die anhand einer die länderspezifischen Einschränkungen und Werte von Flags, entweder der CSD oder der alten Hörsicherheitsstufen (vor Android 14 implementiert) berechnet werden.

Abbildung 2: Berechnung der Schalldosis aktivieren (die Logik wird in Android 14-QPR1).

Zertifizierungsstufe

Bei der Implementierung der HAL-Schnittstelle für die Schalldosis müssen OEMs die in VtsHalAudioCoreTargetTest definierten VTS-Testfälle für die IModule AIDL Audio HAL-Implementierung oder von VtsHalSoundDoseFactoryTargetTest für die eigenständige AIDL HAL-Implementierung mit Tondämpfen.