دوز صدا

اندروید ۱۴ با نظارت مداوم بر اندازه‌گیری‌های دوز صدا و صدور هشدار به کاربران در مورد سطوح آسیب‌زای قرار گرفتن در معرض آن، از دوز صدا در چارچوب صوتی و Audio HAL پشتیبانی می‌کند.

دوز صدا ، اندازه‌گیری سطح فشار صدا در یک دوره زمانی است. با نظارت بر دوز صدا، می‌توانیم به محافظت از کاربران در برابر اثرات مخرب قرار گرفتن در معرض صدای بیش از حد یا طولانی مدت کمک کنیم، در نتیجه هنگام استفاده از هدفون در دستگاه‌های قابل حمل اندروید، محافظت شنوایی بهتری ارائه می‌دهیم و احتمال اختلال شنوایی را به حداقل می‌رسانیم.

استانداردهای جدید برای دستگاه‌های شنوایی ایمن با الزامات نظارتی حفاظت شنوایی در IEC62368-1 ویرایش سوم (نیازمند ورود به سیستم) و EN50332-3 (دسترسی محدود به مشترکین) مطابقت دارد که مفهوم دوز صدا را معرفی می‌کنند.

تابع دوز صدا به تولیدکنندگان اصلی تجهیزات (OEM) اجازه می‌دهد تا از مقررات جدید ایمنی شنوایی پیروی کنند. برای پشتیبانی از دوز صدا، تولیدکنندگان اصلی تجهیزات (OEM) باید مشخصات و مقررات رابط را برای همه سفارشی‌سازی‌ها و گواهینامه‌ها رعایت کنند. یک پیاده‌سازی سفارشی OEM می‌تواند پیاده‌سازی پیش‌فرض دوز صدا در AOSP را دور بزند یا تغییر دهد. با این حال، استفاده از پیاده‌سازی AOSP اکیداً توصیه می‌شود.

محاسبه دوز صدا

استانداردهای IEC62368-1 ویرایش سوم و EN50332-3 با محاسبه دوز صدای محاسبه‌شده (CSD)، دقت اندازه‌گیری مواجهه با صدا را افزایش می‌دهند. CSD با ادغام سطوح مواجهه لحظه‌ای (MEL) در طول زمان محاسبه می‌شود. یک پنجره زمانی هفت روزه پیوسته از مقادیر CSD انباشته‌شده برای محاسبه دوز صدا حفظ می‌شود.

مطابق با بخش 10.6.3.2 از استاندارد IEC62368-1 ویرایش سوم، اگر مقدار CSD به حد 100٪ برسد، سیستم با هر افزایش 100٪، کاربر را از میزان صدا مطلع می‌کند. اگر کاربر هشدار را نپذیرد، میزان صدا به مقدار از پیش تعریف شده منبع انرژی تابشی کلاس 1 (RS1) جدول 39 از استاندارد IEC62368-1 کاهش می‌یابد.

همانطور که در بخش 10.6.3.3 از IEC62368-1 ویرایش سوم ذکر شده است، سیستم باید علاوه بر هشدارهای دوز صدا، هر بار که مقدار MEL از مقدار منبع انرژی تابشی کلاس 2 (RS2) جدول 39 از IEC62368-1 بیشتر شود، یک هشدار مبتنی بر میزان مواجهه را آغاز کند.

برای اخذ گواهینامه با این مقررات و برای مرتبط‌تر کردن مقادیر CSD، سیستم باید از مقادیر خروجی دقیقی که توسط کاربران درک می‌شود (مانند خروجی پخش رسانه) استفاده کند. برای محاسبه CSD مهم است که از مقادیری استفاده شود که نزدیک به سطوح فشار صوتی واقعی باشند که کاربر در معرض آن قرار دارد.

معماری

بسته به محل ضبط فریم‌ها، ویژگی‌های سخت‌افزاری و اثرات مبدل‌ها می‌توانند بر سطح توان فریم‌های رندر شده تأثیر بگذارند. برای اندازه‌گیری دقیق سطح فشار صدای خروجی، ما HAL را گسترش دادیم تا مقادیر MEL را مستقیماً از سخت‌افزار زیرین دریافت کنیم و اثرات احتمالی اعمال شده توسط پردازنده سیگنال دیجیتال (DSP) یا ویژگی‌های بلندگو، مانند امپدانس، حساسیت و پاسخ فرکانسی را در نظر بگیریم.

اگر HAL نتواند مقادیر MEL را ارائه دهد، به عنوان یک مکانیسم جایگزین، چارچوب صوتی CSD را تجزیه و تحلیل و محاسبه می‌کند. این محاسبه در چارچوب صوتی بر اساس اطلاعات مربوط به خروجی رندر شده گزارش شده از HAL و فریم‌هایی است که به DSP صوتی ارسال می‌شوند.

Sound dose دو کامپوننت، SoundDoseHelper و SoundDoseManager, را معرفی می‌کند که در شکل 1 نشان داده شده است:

شکل ۱. اجزای معماری ویژگی دوز صدا.

کمک کننده دوز صدا

کلاس SoundDoseHelper که در فرآیند systemserver قرار دارد، نقطه اصلی جمع‌آوری تمام داده‌های مربوط به دوز صدا است. کلاس AudioService کلاس SoundDoseHelper مدیریت می‌کند.

کلاس SoundDoseHelper مسئول موارد زیر است:

• مدیریت اطلاعات دوز جدید
• مقادیر دوز صدای پایدار
• بازیابی وضعیت در صورت خرابی audioserver
• فعال کردن اعلان‌های رابط کاربری سیستم
• کاهش حجم صدا

مدیر دوز صدا

کلاس SoundDoseManager که در فرآیند audioserver قرار دارد و بخشی از کلاس AudioFlinger است، داده‌های دوز صدا را از HAL جمع‌آوری می‌کند یا آن را به صورت داخلی، به عنوان یک پشتیبان، از فریم‌های ارسال شده به HAL محاسبه می‌کند. کلاس SoundDoseManager داده‌های دوز صدا را به کلاس SoundDoseHelper ارسال می‌کند.

پردازنده مل و تجمیع‌کننده مل

اگر HAL نتواند مقادیر MEL را ارائه دهد، از ابزارهای MelProcessor و MelAggregator در libaudioutils برای محاسبه دوز صدای داخلی استفاده می‌شود.

در کلاس MelProcessor ، محاسبه اصلی با فراخوانی MelProcessor::process(const void* buffer, size_t bytes) روی یک بافر حاوی نمونه‌های صوتی انجام می‌شود. تولیدکنندگان اصلی تجهیزات (OEM) در صورت نیاز می‌توانند MelProcessor در پیاده‌سازی HAL خود استفاده کنند.

کلاس MelAggregator مقادیر MEL را از پورت‌های صوتی مختلف دریافت می‌کند و مقدار CSD را با یک پنجره متغیر هفت روزه محاسبه می‌کند. متد MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel) منطق را اجرا می‌کند. نتایج برای ارتباط با AudioService به کلاس SoundDoseManager ارسال می‌شوند.

پیاده‌سازی

افزونه‌های رابط HIDL از اندروید ۱۴ به بعد منسوخ شده‌اند، بنابراین رابط جدید HAL برای بازیابی مقادیر محاسبه‌شده MEL و صدور هشدارهای مواجهه، با نام ISoundDose ، به عنوان بخشی از AIDL Audio HAL تعریف شده است. با این حال، برای پیاده‌سازی‌هایی که به زمان بیشتری برای ادغام AIDL Audio HAL نیاز دارند، یک رابط مستقل sound dose AIDL HAL داریم که رابط ISoundDoseFactory را ارائه می‌دهد. این رابط در آینده منسوخ خواهد شد.

روش‌های HAL برای پشتیبانی از دوز صدا در نمونه کد زیر نشان داده شده است:

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

رابط کاربری جدید HAL فراخوانی‌های برگشتی را پیاده‌سازی می‌کند که چارچوب را در مورد مواجهه لحظه‌ای مطلع می‌کند و هر زمان که سطح خروجی از RS1 فراتر رود، مقادیر MEL را ارائه می‌دهد. هنگامی که این رابط‌ها پیاده‌سازی می‌شوند، چارچوب از آنها برای گزارش CSD استفاده می‌کند. بدون این پیاده‌سازی فراخوانی، از یک پیاده‌سازی جایگزین در AudioFlinger برای محاسبه تخمین مقادیر CSD استفاده می‌شود.

پشتیبانی AIDL مستقل از دوز صدا

تا زمانی که تولیدکنندگان اصلی تجهیزات (OEM) نتوانند دوز صدا را در HAL صوتی AIDL ادغام کنند، می‌توانند از رابط برنامه‌نویسی مستقل AIDL به نام ISoundDoseFactory به عنوان یک راه حل موقت استفاده کنند. ISoundDoseFactory از رابط ISoundDose استفاده می‌کند، همانطور که در نمونه کد زیر نشان داده شده است:

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

پشتیبانی از دوز صدا AIDL Audio HAL

رابط دوز صدا به عنوان بخشی از AIDL Audio HAL با گسترش رابط IModule ، همانطور که در نمونه کد زیر نشان داده شده است، در درازمدت پشتیبانی می‌شود:

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

این ویژگی، پیاده‌سازی یک آیین‌نامه جدید است که در IEC62368-1 ویرایش سوم و EN50332-3 شرح داده شده است، بنابراین هیچ رابط برنامه‌نویسی کاربردی (API) خارجی وجود ندارد.

تولیدکنندگان اصلی تجهیزات (OEM) می‌توانند با پیاده‌سازی رابط‌های جدید HAL و ارائه داده‌های دقیق MEL برای CSD به چارچوب صوتی (توصیه می‌شود)، یا با ارائه پیاده‌سازی دوز صدای سفارشی، دستگاه‌های خود را تأیید کنند.

محاسبه دوز صدا را فعال کنید

به طور پیش‌فرض، AOSP از منطق ایمنی شنوایی پشتیبانی می‌کند که صدور گواهینامه با استانداردهای موجود EN50332-2 و IEC62368-1 10.6.5 را تضمین می‌کند.

در اندروید ۱۴، محاسبه‌ی دوز صدا به طور پیش‌فرض غیرفعال است.

برای فعال کردن محاسبه دوز صدا با شروع از اندروید ۱۴-QPR1، از دستورالعمل‌های زیر استفاده کنید.

• اگر مقررات مربوط به دوز صدا در کشور شما اجرا می‌شود، بررسی کنید که آیا config_safe_media_volume_enabled در config.xml روی true تنظیم شده است یا خیر.

• برای انطباق با EN50332-3 و IEC62368-1 10.6.3، فروشندگان باید پرچم config_safe_sound_dosage_enabled را در config.xml روی true قرار دهند. برای دستگاه‌هایی که از رمزگشایی offload پشتیبانی می‌کنند و رابط‌های HAL مربوط به دوز صدا را پیاده‌سازی نمی‌کنند، config_safe_sound_dosage_enabled نباید روی true تنظیم شود. در چنین مواردی، تنظیم config_safe_sound_dosage_enabled روی true می‌تواند منجر به مقادیر نادرست CSD و مشکلات صدور گواهینامه برای استانداردهای شنوایی ایمنی شود.

نمودار تصمیم‌گیری زیر، منطقی را شرح می‌دهد که تعیین می‌کند آیا بر اساس محدودیت‌های کشوری و مقادیر پرچم‌ها، CSD یا سطوح ایمنی شنوایی قدیمی (که قبل از اندروید ۱۴ پیاده‌سازی شده بودند) محاسبه شوند یا خیر.

شکل ۲. محاسبه دوز صدا را فعال کنید (منطق در اندروید ۱۴-QPR1 اضافه شده است).

اعتبارسنجی

هنگام پیاده‌سازی رابط HAL برای دوز صدا، تولیدکنندگان اصلی تجهیزات (OEM) باید موارد آزمون VTS تعریف‌شده توسط VtsHalAudioCoreTargetTest برای پیاده‌سازی IModule AIDL Audio HAL یا توسط VtsHalSoundDoseFactoryTargetTest برای پیاده‌سازی مستقل دوز صدا AIDL HAL را اعتبارسنجی کنند.