Android 14 obsługuje dozowanie dźwięku w ramach interfejsu API do obsługi dźwięku 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 ciśnienia akustycznego w określonym czasie. 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 dawkowania dźwięku pozwala producentom OEM przestrzegać nowych przepisów dotyczących bezpieczeństwa 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. Dostosowane wdrożenie OEM mogą ominąć lub zmodyfikować domyślną implementację dawki dźwięku zgodnie z AOSP. 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 narażeniowa jest obliczana przez zintegrowanie chwilowych poziomów ekspozycji (MEL) w czasie. Do obliczenia dawki dźwięku jest używane 7-dniowe okno ruchome z kumulowanymi 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 uzna ostrzeżenia, głośność zmniejszy się do wstępnie zdefiniowanego promieniowania wartość źródła energii 1 (RS1) według 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 akustycznego, rozszerzyliśmy interfejs HAL, aby pobierać wartości MEL bezpośrednio z podstawowego sprzętu i uwzględniać możliwe efekty stosowane przez procesor sygnału cyfrowego (DSP) lub właściwości głośnika, takie jak impedancja, czułość i częstotliwość.
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 zgłoszonym przez HAL oraz klatkach wysyłanych do procesora DSP dźwięku.
Sound dose zawiera 2 składniki: 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
do głównego punktu gromadzenia wszystkich danych. Zajęcia AudioService
zarządzają zajęciami SoundDoseHelper
.
Klasa SoundDoseHelper
odpowiada za:
- Obsługa nowych informacji o dawkowaniu
- Stałe wartości dawki dźwięku
- Stan przywracania po
audioserver
awarii - Uruchamianie powiadomień interfejsu systemu
- Zmniejszam głośność
Menedżer dawki dźwięku
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 MeldAggregator
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 w buforze z atrybutem
próbek audio, wywołując metodę MelProcessor::process(const void* buffer, size_t bytes)
.
W razie potrzeby OEM-y mogą używać MelProcessor
w implementacji HAL.
Klasa MelAggregator
otrzymuje wartości MEL z różnych portów audio i
oblicza wartość CSD w ruchomym oknie wynoszącym 7 dni. Metoda MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel)
uruchamia 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. Pamiętaj jednak:
dla osób wdrażających, które potrzebują więcej czasu na integrację AIDL Audio HAL,
samodzielna dawkowanie dźwięku AIDL HAL, która zapewnia
ISoundDoseFactory
. Będzie to
wycofane w przyszłości.
Metody HAL dotyczące wspomagania dawkowania dźwięku są przedstawione w tym kodzie przykład:
/**
* 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 wywołania zwrotne.
które informują strukturę o ekspozycji chwilowej i określają wartości MEL
gdy poziom wyjściowy przekracza RS1. Gdy te interfejsy zostaną zaimplementowane, framework będzie ich używać do raportowania CSD. Bez implementacji wywołania zwrotnego
implementacja zastępcza w AudioFlinger
jest używany do obliczania szacunków wartości CSD.
Obsługa samodzielnego AIDL w Sound dose
Do czasu, gdy OEM-y będą mogli 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 dawkowania dźwięku jest obsługiwany długoterminowo jako część AIDL Audio HAL przez
rozszerzanie 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 regulacji opisanych w normie IEC62368-1 wersji trzeciej i EN50332-3, w związku z czym nie ma interfejsów API dostępnych dla użytkowników zewnętrznych.
Producenci OEM 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ę bezpieczeństwa słuchu, która zapewnia certyfikację. zgodne z normami EN50332-2 i IEC62368-1 10.6.5.
Na Androidzie 14 obliczanie dawki dźwięku jest wyłączone domyślnie.
Aby umożliwić obliczanie dawki dźwięku, postępuj zgodnie z tymi wytycznymi 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ą nakładać flaga
config_safe_sound_dosage_enabled
wconfig.xml
. dotrue
. W przypadku urządzeń, które obsługują dekodowanie odciążania i nie implementują funkcji interfejsy HAL do dawkowania dźwięku, Poleconfig_safe_sound_dosage_enabled
nie może mieć wartościtrue
. 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 obliczać CSD, czy starsze poziomy ochrony słuchu (wdrożone przed Androidem 14).
Rysunek 2. Włącz obliczanie dawki dźwięku (logika jest dodana w Android 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.