Lautstärke

Android 14 unterstützt die Schalldosis im Audio-Framework und in der Audio-HAL. Dazu werden die Messwerte für die Schalldosis kontinuierlich erfasst und Nutzer werden vor schädlichen Expositionsstufen gewarnt.

Die Schalldosis ist ein Maß für den Schalldruckpegel über einen bestimmten Zeitraum. Durch die Erfassung der Schalldosis können wir Nutzer vor den schädlichen Auswirkungen einer übermäßigen oder längeren Schallbelastung 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örbeeinträchtigung.

Die neuen Standards für sichere Hörgeräte entsprechen den gesetzlichen Anforderungen für den Gehörschutz in der dritten Überarbeitung der IEC-Norm 62368-1 (Anmeldung erforderlich) und der EN-Norm 50332-3 (Zugriff nur für Abonnenten). In diesen Normen wird das Konzept der Schalldosis eingeführt.

Mit der Funktion zur Erfassung der Schalldosis können OEMs die neuen Vorschriften zum Gehörschutz einhalten. Um die Schalldosis zu unterstützen, müssen OEMs die Schnittstellenspezifikationen und ‑vorschriften für alle Anpassungen und Zertifizierungen einhalten. Eine angepasste OEM-Implementierung kann die AOSP-Standardimplementierung der Schalldosis umgehen oder ändern. Wir empfehlen jedoch dringend, die AOSP-Implementierung zu verwenden.

Berechnung der Schalldosis

Die Standards in der dritten Überarbeitung der IEC-Norm 62368-1 und der EN-Norm 50332-3 erhöhen die Genauigkeit der Messung der Schallbelastung durch die Berechnung der berechneten Schalldosis (CSD). Die CSD wird berechnet, indem die zeitlich begrenzte Exposition (MEL) im Zeitverlauf integriert wird. Für die Berechnung der Schalldosis wird ein kontinuierlich rollierendes 7‑Tage-Fenster mit kumulierten CSD-Werten verwendet.

Gemäß Abschnitt 10.6.3.2 der dritten Überarbeitung der IEC-Norm 62368-1 wird der Nutzer vom System über die Schallpegel informiert, wenn der CSD-Wert das Limit von 100% erreicht. Dies geschieht bei jeder Erhöhung um 100%. Wenn der Nutzer die Warnung nicht bestätigt, wird die Lautstärke auf den vordefinierten Wert der Strahlungsenergiequellenklasse 1 (RS1) aus Tabelle 39 der IEC-Norm 62368-1 gesenkt.

Wie in Abschnitt 10.6.3.3 der dritten Überarbeitung der IEC-Norm 62368-1 erwähnt, muss das System neben den Warnungen zur Schalldosis jedes Mal eine expositionsbasierte Warnung ausgeben, wenn der MEL-Wert den Wert der Strahlungsenergiequellenklasse 2 (RS2) aus Tabelle 39 der IEC-Norm 62368-1 überschreitet.

Für die Zertifizierung gemäß diesen Vorschriften und um die CSD-Werte relevanter zu machen, muss das System genaue Ausgabewerte verwenden, wie sie von den Nutzern wahrgenommen werden (z. B. die Ausgabe der Medienwiedergabe). Für die CSD-Berechnung müssen Werte verwendet werden, die nahe an den tatsächlichen Schalldruckpegeln liegen, denen der Nutzer ausgesetzt ist.

Architektur

Je nachdem, wo die Frames erfasst werden, können die Hardwareeigenschaften und die Auswirkungen der Wandler den Leistungspegel der gerenderten Frames beeinflussen. Um den Schalldruckpegel der Ausgabe genau zu messen, haben wir die HAL erweitert, um die MEL-Werte direkt von der zugrunde liegenden Hardware zu erhalten und mögliche Auswirkungen zu berücksichtigen, die vom digitalen Signalprozessor (DSP) oder von Lautsprechereigenschaften wie Impedanz, Empfindlichkeit und Frequenzgang verursacht werden.

Wenn die HAL keine MEL-Werte liefern kann, analysiert und berechnet das Audio-Framework als Fallback-Mechanismus die CSD. Diese Berechnung im Audio-Framework basiert auf den Informationen zur gerenderten Ausgabe, die von der HAL gemeldet werden, und auf den Frames, die an den Audio-DSP gesendet werden.

Mit der Schalldosis werden zwei Komponenten eingeführt: SoundDoseHelper und SoundDoseManager,. Sie sind in Abbildung 1 dargestellt:

Abbildung 1 : Architekturkomponenten der Funktion zur Erfassung der Schalldosis.

SoundDoseHelper

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

Die Klasse SoundDoseHelper ist für Folgendes zuständig:

• Verarbeitung neuer Dosierungsinformationen
• Speichern von Schalldosiswerten
• Wiederherstellung des Status bei einem audioserver-Absturz
• Auslösen von Benachrichtigungen der System-UI
• Verringern der Lautstärke

SoundDoseManager

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

MelProcessor und MelAggregator

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

In der MelProcessor Klasse wird die Hauptberechnung für einen Puffer mit Audiodaten ausgeführt, indem MelProcessor::process(const void* buffer, size_t bytes) aufgerufen wird. OEMs können MelProcessor bei Bedarf in ihrer HAL-Implementierung verwenden.

Die Klasse MelAggregator empfängt die MEL-Werte von verschiedenen Audio-Ports und berechnet den CSD-Wert mit einem rollierenden 7‑Tage-Fenster. Die Logik wird mit der Methode MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) ausgeführt. Die Ergebnisse werden an die Klasse SoundDoseManager gesendet, um mit AudioService zu kommunizieren.

Implementierung

HIDL-Schnittstellenerweiterungen sind ab Android 14 veraltet. Daher wird die neue HAL-Schnittstelle zum Abrufen berechneter MEL-Werte und zum Ausgeben von Expositionswarnungen mit dem Namen ISoundDose, als Teil der AIDL-Audio-HAL definiert. Für Implementierer, die mehr Zeit für die Integration der AIDL-Audio-HAL benötigen, haben wir jedoch eine eigenständige AIDL-HAL für die Schalldosis, die die ISoundDoseFactory Schnittstelle bietet. Diese wird in Zukunft veraltet sein.

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

/**
 * 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 das Framework über die zeitlich begrenzte Exposition informieren und MEL-Werte liefern , wenn der Ausgabewert RS1 überschreitet. Wenn diese Schnittstellen implementiert sind, verwendet das Framework sie für die CSD-Berichterstellung. Ohne diese Callback-Implementierung, wird eine Fallback-Implementierung in AudioFlinger verwendet, um Schätzungen der CSD-Werte zu berechnen.

Hinweis: Durch das Offloading der Dekodierung von komprimiertem Audio wird der Akkuverbrauch optimiert, indem komprimierte Audiodaten direkt an den DSP gestreamt werden, ohne den Host-App Prozessor zu aktivieren. Bei einer solchen Hardware-Offload-Dekodierung hat das Framework nur Zugriff auf komprimierte Audiodaten und kann keine MEL-Werte schätzen. Wenn in dieser Situation die AOSP-Implementierung der Schalldosis verwendet wird, kann ein Gerät die Vorschriften der EN-Norm 50332-3 und der IEC-Norm 62368-1 nur einhalten, wenn MEL-Werte über die HAL-Schnittstelle bereitgestellt werden.

Eigenständige AIDL-Unterstützung für die 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 Schnittstelle ISoundDose, 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);
}

Unterstützung der AIDL-Audio-HAL für die Schalldosis

Die Schnittstelle für die Schalldosis wird langfristig als Teil der AIDL-Audio-HAL 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();
}

Diese Funktion ist eine Implementierung einer neuen Vorschrift, die in der dritten Überarbeitung der IEC-Norm 62368-1 und der EN-Norm 50332-3 beschrieben ist. Daher gibt es keine externen APIs.

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

Berechnung der Schalldosis aktivieren

Standardmäßig unterstützt AOSP die Logik für den Gehörschutz, die die Zertifizierung gemäß den bestehenden Standards EN 50332-2 und IEC 62368-1 10.6.5 gewährleistet.

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

Achtung: Aktivieren Sie die Berechnung der Schalldosis nicht für die Android 14-Version. Die Logik zur Unterstützung der Berechnung der Schalldosis wird erst ab Android 14-QPR1 implementiert. Diese Logik zum Aktivieren der CSD ist in Android 14 nicht voll funktionsfähig und kann zu Ungenauigkeiten bei der CSD mit Bluetooth-Geräten führen.

Folgen Sie der Anleitung unten, um die Berechnung der Schalldosis ab Android 14-QPR1 zu aktivieren.

• Wenn die Vorschriften zur Schalldosis in Ihrem Land durchgesetzt werden, prüfen Sie, ob config_safe_media_volume_enabled in config.xml auf true gesetzt ist.

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

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

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

Das folgende Entscheidungsdiagramm beschreibt die Logik, die anhand der länderspezifischen Einschränkungen und der Werte der Flags bestimmt, ob die CSD oder die älteren Gehörschutzstufen (implementiert vor Android 14) berechnet werden.

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

Validierung

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