Android 14 obsługuje dozowanie dźwięku w ramach interfejsu API Audio i Audio HAL, stale monitorując pomiary dawki dźwięku oraz wysyłając użytkownikom ostrzeżenia o szkodliwych poziomach ekspozycji.
Dawka dźwięku to pomiar poziomu ciśnienia akustycznego w danym okresie. Dzięki monitorowaniu dawki dźwięku możemy chronić użytkowników przed szkodliwymi skutkami nadmiernego lub długotrwałego narażenia na dźwięk, zapewniając lepszą ochronę słuchu podczas korzystania ze słuchawek na przenośnych urządzeniach z Androidem i minimalizując ryzyko wystąpienia u nich niedosłuchu.
Nowe standardy dotyczące bezpiecznych urządzeń do słuchania są zgodne z wymaganiami regulacyjnymi dotyczącymi ochrony słuchu w normach IEC62368-1 w 3 edycji (wymagającej zalogowania) i EN50332-3 (z dostępem ograniczonym do subskrybentów), które wprowadzają pojęcie dawki dźwięku.
Funkcja dawki dźwięku pozwala producentom urządzeń na przestrzeganie nowych przepisów dotyczących ochrony słuchu. Aby obsługiwać funkcję sound dose, producenci OEM muszą przestrzegać specyfikacji i regulacji dotyczących interfejsu w przypadku wszystkich dostosowań i certyfikatów. Niestandardowe wdrożenie OEM może pominąć lub zmodyfikować domyślne wdrożenie AOSP dotyczące dozowania dźwięku. Zdecydowanie zalecamy jednak korzystanie z implementacji AOSP.
Obliczanie dawki dźwięku
Standardy IEC62368-1 w 3 edycji i EN50332-3 zwiększają dokładność pomiaru ekspozycji na hałas poprzez obliczenie obliczonej dawki dźwięku (CSD). Średnia dawka skuteczna jest obliczana przez zintegrowanie chwilowych poziomów ekspozycji w czasie. Do obliczenia dawki dźwięku jest używane 7-dniowe okno ruchome z wartościami CSD.
Zgodnie z sekcją 10.6.3.2 normy IEC62368-1 w wersji 3, jeśli wartość CSD osiągnie limit 100%, system powiadamia użytkownika o poziomie dźwięku przy każdym wzroście o 100%. Jeśli użytkownik nie potwierdzi ostrzeżenia, głośność zostanie obniżona do wstępnie zdefiniowanej wartości klasy 1 (RS1) źródła energii w tabeli 39 normy IEC62368-1.
Zgodnie z sekcją 10.6.3.3 normy IEC62368-1 w wersji 3 system musi inicjować ostrzeżenia o narażeniu na promieniowanie za każdym razem, gdy wartość MEL przekracza wartość źródła promieniowania o klasie 2 (RS2) podana w tabeli 39 normy IEC62368-1.
Aby uzyskać certyfikat zgodności z tymi przepisami i uczynić wartości CSD bardziej trafnymi, system musi używać dokładnych wartości wyjściowych postrzeganych przez użytkowników (np. wyjściowych wartości odtwarzania multimediów). Ważne jest, aby obliczenia CSD używały wartości zbliżonych do rzeczywistych poziomów ciśnienia akustycznego, na które narażony jest użytkownik.
Architektura
W zależności od tego, gdzie są rejestrowane klatki, na moc renderowanych klatek mogą mieć wpływ właściwości sprzętu i efekty przetworników. Aby uzyskać dokładne pomiary poziomu ciśnienia dźwięku na wyjściu, rozszerzyliśmy interfejs HAL, aby pobierać wartości MEL bezpośrednio z podstawowego sprzętu i uwzględniać możliwe efekty stosowane przez procesor cyfrowy (DSP) lub właściwości głośnika, takie jak impedancja, czułość i charakterystyka częstotliwości.
Jeśli HAL nie może podać wartości MEL, jako mechanizm awaryjny mechanizm audio analizuje i oblicza CSD. To obliczenie w ramach audio jest oparte na informacjach o wyrenderowanym wyjściu z HAL i ramkach wysyłanych do procesora DSP audio.
Sound dose zawiera 2 komponenty: SoundDoseHelper
i SoundDoseManager,
, jak pokazano na rysunku 1:
Rysunek 1. Składniki architektoniczne funkcji dawki dźwięku.
SoundDoseHelper
Klasa SoundDoseHelper
, która znajduje się w procesie systemserver
, jest głównym punktem zbierania wszystkich istotnych danych dotyczących dozowania dźwięku. Zajęcia AudioService
zarządzają zajęciami SoundDoseHelper
.
Klasa SoundDoseHelper
odpowiada za:
- Przetwarzanie nowych informacji o dawce
- Zapisywanie wartości dawki dźwięku
- Przywracanie stanu w przypadku awarii
audioserver
- Uruchamianie powiadomień interfejsu systemu
- Zmniejszanie głośności
SoundDoseManager
Klasa SoundDoseManager
, która działa w procesie audioserver
i jest częścią klasy AudioFlinger
, zbiera dane o dawkach dźwięku z interfejsu HAL lub oblicza je wewnętrznie, jako alternatywę, z ramek wysyłanych do interfejsu HAL. Klasa SoundDoseManager
wysyła dane dotyczące dawki dźwięku do klasy SoundDoseHelper
.
MelProcessor i MelAggregator
Jeśli HAL nie może podać wartości MEL, do obliczenia dawki dźwięku wewnętrznego używane są narzędzia MelProcessor
i MelAggregator
w libaudioutils
.
W klasie MelProcessor
główne obliczenia są wykonywane na buforze z próbkami audio przez wywołanie funkcji MelProcessor::process(const void* buffer, size_t bytes)
.
W razie potrzeby OEM-y mogą używać MelProcessor
w swojej implementacji HAL.
Klasa MelAggregator
otrzymuje wartości MEL z różnych portów audio i oblicza wartość CSD w ruchomym oknie 7 dni. Metoda MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel)
wykonuje logikę. Wyniki są wysyłane do klasy SoundDoseManager
w celu komunikacji z uczniami AudioService
.
Implementacja
Rozszerzenia interfejsu HIDL zostały wycofane od Androida 14, dlatego nowy interfejs HAL do pobierania obliczonych wartości MEL i wydawania ostrzeżeń dotyczących ekspozycji o nazwie ISoundDose
jest zdefiniowany jako część interfejsu AIDL Audio HAL. Dla implementatorów, którzy potrzebują więcej czasu na zintegrowanie interfejsu AIDL Audio HAL, udostępniamy samodzielny interfejs AIDL HAL do dozowania dźwięku, który oferuje interfejs ISoundDoseFactory
. W przyszłości zostanie on wycofany.
Metody HAL obsługujące dozowanie dźwięku:
/**
* 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);
}
}
Nowy interfejs HAL implementuje funkcje zwrotne, które informują framework o chwilkowej ekspozycji i przekazują wartości MEL, gdy poziom wyjściowy przekracza RS1. Gdy te interfejsy zostaną zaimplementowane, framework będzie ich używać do raportowania CSD. Bez tej implementacji funkcji wywołania zwrotnego do obliczenia szacowanych wartości CSD używana jest implementacja zastępcza AudioFlinger
.
Obsługa samodzielnego AIDL w Sound dose
Do czasu, gdy OEM-y będą mogły zintegrować dźwięk w interfejsie HAL dźwięku AIDL, mogą używać samodzielnego interfejsu AIDL API ISoundDoseFactory
jako rozwiązania zastępczego. ISoundDoseFactory
używa interfejsu ISoundDose
, jak pokazano w tym przykładowym kodzie:
@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);
}
Obsługa HAL dźwięku AIDL przez Sound Dose
Interfejs sound dose jest długoterminowo obsługiwany w ramach interfejsu HAL Audio w AIDL poprzez rozszerzenie interfejsu IModule
, jak pokazano w tym przykładowym kodzie:
@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();
}
Ta funkcja jest implementacją nowych przepisów opisanych w normie IEC 62368-1 w 3 edycji i EN 50332-3, więc nie ma interfejsów API skierowanych na zewnątrz.
Producenci urządzeń mogą certyfikować swoje urządzenia, wdrażając nowe interfejsy HAL i dostarczając do frameworku audio (zalecane) dokładne dane MEL dotyczące CSD lub udostępniając niestandardową implementację dawki dźwięku.
Włączanie obliczania dawki dźwięku
Domyślnie AOSP obsługuje logikę ochrony słuchu, która zapewnia certyfikację zgodnie z obowiązującymi standardami EN50332-2 i IEC62368-1 10.6.5.
W Androidzie 14 domyślnie wyłączone jest obliczanie dawki dźwięku.
Aby włączyć obliczanie dawki dźwięku, postępuj zgodnie z tymi wskazówkami. Funkcja jest dostępna od Androida 14-QPR1.
Jeśli w Twoim kraju obowiązują przepisy dotyczące dawki dźwięku, sprawdź, czy parametr
config_safe_media_volume_enabled
w sekcjiconfig.xml
jest ustawiony natrue
.Aby zachować zgodność z normami EN50332-3 i IEC62368-1 10.6.3, dostawcy muszą zastosować flagę
config_safe_sound_dosage_enabled
wconfig.xml
dotrue
. W przypadku urządzeń, które obsługują odciążanie dekodowania i nie implementują interfejsów HAL doz, wartośćconfig_safe_sound_dosage_enabled
nie może być ustawiona natrue
. W takich przypadkach ustawienie wartościconfig_safe_sound_dosage_enabled
natrue
może spowodować nieprawidłowe wartości CSD i problemy z certyfikacją w przypadku standardów bezpieczeństwa słuchu.
Poniższy schemat podejmowania decyzji opisuje logikę, która na podstawie ograniczeń w danym kraju i wartości flag decyduje, czy należy obliczyć poziom CSD, czy starszy poziom bezpieczeństwa słuchowego (wprowadzony przed Androidem 14).
Rysunek 2. Włączanie obliczania dawki dźwięku (logika została dodana w Androidzie 14-QPR1).
Weryfikacja
Podczas implementacji interfejsu HAL na potrzeby dźwięku dozowego OEM musi przeprowadzić weryfikację za pomocą przypadków testowych VTS zdefiniowanych przez VtsHalAudioCoreTargetTest
w przypadku implementacji interfejsu HAL dla dźwięku AIDL w IModule lub przez VtsHalSoundDoseFactoryTargetTest
w przypadku samodzielnej implementacji interfejsu HAL dla dźwięku dozowego w AIDL.