Sound dose

Android 14 provides support for sound dose in the audio framework and Audio HAL by continuously monitoring sound dose measurements and issuing warnings to users about damaging exposure levels.

Sound dose is a measurement of sound pressure levels over a period of time. By monitoring sound dose, we can help protect users from the damaging effects of excessive or prolonged sound exposure, thus offering better hearing protection when using headphones on portable Android devices and minimizing the chance of a hearing impairment.

The new standards for safe listening devices conform to the regulatory requirements for hearing protection in IEC62368-1 3rd edition (requires login) and EN50332-3 (access limited to subscribers), which introduce the concept of sound dose.

The sound dose function lets OEMs follow the new hearing safety regulations. To support sound dose, OEMs must follow interface specifications and regulations for all customizations and certifications. A customized OEM implementation can bypass or modify the AOSP default implementation of sound dose. However, using the AOSP implementation is highly recommended.

Sound dose calculation

The standards in IEC62368-1 3rd edition and EN50332-3 increase the accuracy of measuring sound exposure by computing the calculated sound dose (CSD). CSD is computed by integrating momentary exposure levels (MEL) over time. A seven-day continuously rolling window of accumulated CSD values is maintained for the sound dose computation.

In accordance with section 10.6.3.2 of IEC62368-1 3rd edition, if the CSD value reaches the 100% limit, the system alerts the user about the sound levels on each increase of 100%. If the user doesn’t acknowledge the warning, the volume lowers to the predefined radiation energy source class 1 (RS1) value of Table 39 of IEC62368-1.

As mentioned in section 10.6.3.3 of IEC62368-1 3rd edition, along with the sound dose warnings the system must initiate an exposure-based warning every time the MEL value exceeds the radiation energy source class 2 (RS2) value of Table 39 of IEC62368-1.

For certification with these regulations and to make the CSD values more relevant, the system must use accurate output values as perceived by the users (such as the media playback output). It's important for the CSD computation to use values that are close to the actual sound pressure levels to which the user is exposed.

Architecture

Depending on where the frames are captured, hardware characteristics and effects of the transducers can influence the power level of the rendered frames. To have a precise output sound pressure level measurement, we extended the HAL to get the MEL values directly from the underlying hardware and account for possible effects that are applied by the digital signal processor (DSP) or speaker properties, such as impedance, sensitivity, and frequency response.

If the HAL can’t provide MEL values, as a fallback mechanism, the audio framework analyzes and computes CSD. This computation in the audio framework is based on the information about the rendered output reported from HAL, and frames that are sent to the audio DSP.

Sound dose introduces two components, SoundDoseHelper and SoundDoseManager, as shown in Figure 1:

sound_dose_arch

Figure 1. Architectural components of the sound dose feature.

SoundDoseHelper

The SoundDoseHelper class, which lives in the systemserver process, is the main collection point for all relevant sound dosing data. The AudioService class manages the SoundDoseHelper class.

The SoundDoseHelper class is responsible for the following:

Handling new dosage information
Persisting sound dose values
Recovering state in case of audioserver crash
Triggering System UI notifications
Lowering volume

SoundDoseManager

The SoundDoseManager class, which lives in the audioserver process and is part of the AudioFlinger class, collects the sound dose data from the HAL or computes it internally, as a fallback, from the frames sent to the HAL. The SoundDoseManager class sends the sound dose data to the SoundDoseHelper class.

MelProcessor and MelAggregator

If the HAL can't provide MEL values, the MelProcessor and MelAggregator utilities in libaudioutils are used for the internal sound dose computation.

In the MelProcessor class, the main computation is performed on a buffer with audio samples by calling MelProcessor::process(const void* buffer, size_t bytes). OEMs can use MelProcessor in their HAL implementation if needed.

The MelAggregator class receives the MEL values from different audio ports and calculates the CSD value with a rolling window of seven days. The method MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) executes the logic. The results are sent to the SoundDoseManager class for communication with AudioService.

Implementation

HIDL interface extensions are deprecated starting with Android 14, so the new HAL interface for retrieving computed MEL values and issuing exposure warnings, named ISoundDose, is defined as part of the AIDL Audio HAL. However, for implementers that need more time to integrate the AIDL Audio HAL, we have a standalone sound dose AIDL HAL, which offers the ISoundDoseFactory interface. This will be deprecated in the future.

The HAL methods for sound dose support are shown in the following code sample:

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

The new HAL interface implements callbacks that inform the framework about momentary exposure and provides MEL values whenever the output level exceeds RS1. When these interfaces are implemented, the framework uses them for CSD reporting. Without this callback implementation, a fallback implementation on AudioFlinger is used to calculate estimates of CSD values.

Sound dose standalone AIDL support

Until OEMs can integrate sound dose in the AIDL audio HAL, they can use the standalone AIDL API ISoundDoseFactory as a workaround. ISoundDoseFactory uses the ISoundDose interface, as shown in the following code sample:

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

Sound dose AIDL Audio HAL support

The sound dose interface is supported long term as part of the AIDL Audio HAL by extending the IModule interface, as shown in the following code sample:

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

This feature is an implementation of a new regulation described in IEC62368-1 3rd edition and EN50332-3, so there are no external-facing APIs.

OEMs can certify their devices by implementing the new HAL interfaces and providing accurate MEL data for CSD to the audio framework (recommended), or by providing a custom sound dose implementation.

Enable the calculation of sound dose

By default, AOSP supports the hearing safety logic that ensures certification with the existing EN50332-2 and IEC62368-1 10.6.5 standards.

In Android 14, calculation of sound dose is disabled by default.

Use the following guidelines to enable the calculation of sound dose starting with Android 14-QPR1.

If the sound dose regulations are enforced in your country, check if config_safe_media_volume_enabled in config.xml is set to true.

Note: In countries where the regulations aren't enforced, OEMs can enable or disable CSD through SysUI, such as a toggle in the Settings page, or an app setting.
To be compliant with EN50332-3 and IEC62368-1 10.6.3, vendors must overlay the config_safe_sound_dosage_enabled flag in config.xml to true. For devices that support offload decoding and don't implement the sound dose HAL interfaces, config_safe_sound_dosage_enabled mustn't be set to true. In such cases, setting config_safe_sound_dosage_enabled to true can lead to inaccurate CSD values and certification issues for safety hearing standards.

Note: OEMs can set the config_safe_sound_dose_enabled flag for specific countries by overriding the flag in frameworks/base/core/res/res/values-mcc${XX}/config.xml where XX represents the mobile country code (MCC) of the country.

The following decision graph describes the logic that determines if, based on the country restrictions and values of flags, either the CSD or the legacy hearing safety levels (implemented prior to Android 14) are calculated.

enable_csd

Figure 2. Enable the calculation of sound dose (the logic is added in Android 14-QPR1).

Validation

When implementing the HAL interface for sound dose, OEMs must validate against the VTS test cases defined by VtsHalAudioCoreTargetTest for the IModule AIDL Audio HAL implementation, or by VtsHalSoundDoseFactoryTargetTest for the standalone sound dose AIDL HAL implementation.