इस पेज का अनुवाद Cloud Translation API से किया गया है.

HIDL ऑडियो एचएएल

Android 13 और उससे पहले के वर्शन में, ऑडियो एचएएल इंटरफ़ेस को HIDL का इस्तेमाल करके, एचएएल फ़ाइलों (एक्सटेंशन .hal के साथ) में और कॉन्फ़िगरेशन फ़ाइलों के लिए XSD स्कीमा में तय किया गया है. इनका उदाहरण यहां दिया गया है.

audio_hal

पहली इमेज. ऑडियो एचएएल इंटरफ़ेस.

कॉन्फ़िगरेशन फ़ाइलें

ऑडियो नीति और ऑडियो इफ़ेक्ट की एक्सएमएल कॉन्फ़िगरेशन फ़ाइलों को ऑडियो एचआईडीएल एचएएल इंटरफ़ेस का हिस्सा माना जाता है. ये फ़ाइलें अपने स्कीमा के मुताबिक होनी चाहिए. साथ ही, इनके स्कीमा के मुताबिक होने की पुष्टि, वीटीएस टेस्ट से की जाती है.

ऑडियो HIDL HAL लागू करने के लिए, आपको एक ऐसी ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल बनानी होगी जिसमें ऑडियो टोपोलॉजी के बारे में जानकारी हो. फ़्रेमवर्क का इस्तेमाल करने के लिए, ऑडियो एचएएल की सुविधाओं के बारे में audio_policy_configuration.xml फ़ाइल में एलान किया जाना चाहिए.

Audio HIDL HAL API

इस सेक्शन में, HIDL के लिए कोर, इफ़ेक्ट, और सामान्य एचएएल एपीआई के बारे में बताया गया है.

कोर एचएएल

HIDL का इस्तेमाल करने वाले Core HAL के कुछ मुख्य इंटरफ़ेस यहां दिए गए हैं:

IDeviceFactory.hal, एपीआई का एंट्री पॉइंट है.
IDevice.hal और IPrimaryDevice.hal में setMasterVolume या openInputStream जैसे तरीके शामिल होते हैं.
स्ट्रीम एकतरफा होती हैं. AudioFlinger का इस्तेमाल, IStream.hal, IStreamOut.hal, और IStreamIn.hal के ज़रिए HAL से ऑडियो भेजने या पाने के लिए किया जाता है.

इस टेबल में, काम के Core HAL HIDL कॉम्पोनेंट की जगह की जानकारी दी गई है:

मुख्य HAL कॉम्पोनेंट	जगह की जानकारी
एपीआई का नया वर्शन	`/hardware/interfaces/audio/6.0`
Core HAL API के नए वर्शन के लिए खास टाइप	`/hardware/interfaces/audio/6.0/types.hal`
ऑडियो नीति की कॉन्फ़िगरेशन फ़ाइल का XSD स्कीमा	`/hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd`

Core HAL API (/hardware/interfaces/audio/core/all-versions/default/) का डिफ़ॉल्ट तौर पर लागू होने वाला वर्शन, Treble HAL के लागू होने से पहले के वर्शन के आस-पास एक रैपर होता है. इसमें लेगसी शेयर की गई लाइब्रेरी का इस्तेमाल किया जाता है. डिफ़ॉल्ट तौर पर लागू करने की सुविधा को रेफ़रंस के तौर पर भी इस्तेमाल किया जा सकता है. ऐसा तब किया जाता है, जब ऑडियो एचएएल के नए वर्शन लागू किए जाते हैं, जो सीधे कर्नेल ड्राइवर के साथ इंटरैक्ट करते हैं.

इफ़ेक्ट एचएएल

नीचे दी गई टेबल में, एफ़ेक्ट एचएएल के उन काम के कॉम्पोनेंट की जगह दी गई है जिनमें HIDL का इस्तेमाल किया गया है:

इफ़ेक्ट HAL कॉम्पोनेंट	जगह की जानकारी
एपीआई का नया वर्शन	`/hardware/interfaces/audio/effect/6.0/`
इफ़ेक्ट कॉन्फ़िगरेशन फ़ाइल का XSD स्कीमा	`/hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd`

ज़्यादा जानकारी के लिए, /hardware/interfaces/audio/effect/all-versions/default/ पर जाकर, इफ़ेक्ट HAL API के लागू होने का सैंपल देखें. साथ ही, ऑडियो इफ़ेक्ट सेक्शन भी देखें.

कॉमन एचएएल

HIDL का इस्तेमाल करने वाले Common HAL API में ये चीज़ें शामिल हैं:

Core और Effect API के साथ शेयर की गई परिभाषाएं (/hardware/interfaces/audio/common/6.0/types.hal).
यूटिलिटी (/hardware/interfaces/audio/common/all-versions), जिन्हें लागू करने, क्लाइंट, और टेस्ट के लिए, HIDL एपीआई के हिसाब से कोडिंग करने में मदद करने के लिए इस्तेमाल किया जाता है.

Audio HAL V7 में किए गए अपडेट

Android 12 में, ऑडियो एचएएल के वर्शन 7 में अहम बदलाव किए गए हैं. इनके बारे में इस सेक्शन में बताया गया है. Audio HAL V7 ये काम करता है:

फ़्रेमवर्क और HAL के इस्तेमाल किए गए डेटा मॉडल को एक साथ जोड़ता है.
ऑडियो नीति के कॉन्फ़िगरेशन के लिए इस्तेमाल किए गए एक्सएमएल स्कीमा और HIDL डेटा टाइप (एन्सम) के बीच डुप्लीकेट डेटा को कम करता है.

खास तौर पर, Audio HAL V7 में इन हिस्सों में बदलाव किए गए हैं:

एनोमेरेशन टाइप
डेटा टाइप
वेंडर टैग
वेंडर एक्सटेंशन के लिए नेमस्पेस

इन बदलावों के बारे में, उनके सेक्शन में ज़्यादा जानकारी दी गई है.

एनोटेशन

Audio HAL V7 से, ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल में इस्तेमाल किए गए एनोटेट किए गए टाइप, सिर्फ़ XSD स्कीमा में तय किए जाते हैं, न कि HIDL में.

Audio HAL V6 में, types.hal में मौजूद वैल्यू, जैसे कि AudioFormat को ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल के XSD स्कीमा में भी तय किया गया है. इससे डुप्लीकेट वैल्यू बनती है. V7 में इस समस्या से बचने के लिए, एनम टाइप को string में बदल दिया गया है. साथ ही, सभी संभावित एनमेशन वैल्यू को XSD स्कीमा में शामिल किया गया है.

दूसरे चित्र में, V7 में AudioFormat enum टाइप में किए गए कुछ बदलावों की तुलना की गई है:

audioformat-change

दूसरी इमेज. AudioFormat enum में किए गए कुछ बदलावों की तुलना.

string में बदले गए वैल्यू के टाइप के बारे में जानने के लिए, नीचे दी गई सूची देखें:

AudioChannelMask
AudioContentType
AudioDevice: वेंडर एक्सटेंसिबल
AudioFormat: वेंडर एक्सटेंसिबल
AudioGainMode
AudioSource
AudioStreamType
AudioUsage

स्ट्रिंग की enum वैल्यू पास करना

स्ट्रिंग वैल्यू का इस्तेमाल, एचएएल इंटरफ़ेस की सीमा के पार, जानकारी को एनिमेंशन वैल्यू के तौर पर ट्रांसफ़र करने के लिए किया जाता है. फ़्रेमवर्क और एचएएल रैपर, दोनों ही कारोबारी लॉजिक को लागू करने के लिए, पूर्णांक वाली वैल्यू का इस्तेमाल करते हैं. साथ ही, तीसरी इमेज में दिखाए गए कन्वर्ज़न के तरीके का इस्तेमाल करते हैं:

audio-passing-values

तीसरी इमेज. स्ट्रिंग के तौर पर enum वैल्यू पास करना.

ध्यान दें: हमारे एपीआई के लिए, यहां स्ट्रिंग का इस्तेमाल करना असामान्य या अप्रभावी लग सकता है. हमने स्ट्रिंग का इस्तेमाल इसलिए किया है, ताकि HIDL और XSD फ़ाइलों के बीच, एनिमरेशन के कॉन्स्टेंट की डुप्लीकेट कॉपी न हो. साथ ही, वेंडर एक्सटेंशन जोड़ने की प्रोसेस को आसान बनाया जा सके. हमारा सुझाव है कि एनम को सिर्फ़ तब स्ट्रिंग के तौर पर दिखाएं, जब उन्हें एचएएल इंटरफ़ेस पर भेजना हो. हमारा सुझाव है कि कारोबारी लॉजिक में, स्ट्रिंग के तौर पर दिखाए गए एन्यूमरेशन का इस्तेमाल न करें. ऐसा इसलिए, क्योंकि बूलियन लॉजिक ऑपरेशन लागू करने और तुलना करने वाली मैपिंग के नतीजे में, इससे जुड़ा ओवरहेड होता है.

उदाहरण के लिए, फ़्रेमवर्क से वेंडर को ऑडियो फ़ॉर्मैट टाइप की वैल्यू पास करने के लिए:

AudioFormat की वैल्यू को libaudiohal में स्ट्रिंग वैल्यू में बदला जाता है और इसे HAL को पास किया जाता है.
HAL की ओर से, डिफ़ॉल्ट रैपर स्ट्रिंग को एक सूची वाली वैल्यू में बदल देता है. इसे लेगसी HAL को पास किया जाता है.

एक्सएमएल स्कीमा में हुए बदलाव

एक्सएमएल स्कीमा डेफ़िनिशन (एक्सएसडी) में, सूची में शामिल वैल्यू की पूरी सूची होने पर, ऑडियो नीति कॉन्फ़िगरेशन की एक्सएमएल फ़ाइल की पुष्टि, वीटीएस की मदद से बेहतर तरीके से की जा सकती है. हमने XSD का पालन करने के लिए, HAL V7 के साथ इस्तेमाल की जाने वाली ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल में बदलाव किए हैं.

वर्शन 7 में, एट्रिब्यूट (जैसे, सैंपलिंग रेट, चैनल मास्क, और फ़्लैग) की वैल्यू की सूचियों को अलग करने के लिए, स्टैंडर्ड ␣ (स्पेस) वर्ण का इस्तेमाल किया जाता है. यह वर्शन 6 और उससे पहले के वर्शन में इस्तेमाल किए गए , (कॉमा) और | (वर्टिकल बार) सिंबल के बजाय इस्तेमाल किया जाता है. नीचे दिए गए उदाहरण में, channelMasks के लिए वैल्यू की सूची को अलग करने के लिए, स्पेस का इस्तेमाल किया गया है:

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

सिंबल में बदलाव करने के लिए, update_audio_policy_config.sh नाम की ऑटोमैटिक कन्वर्ज़न स्क्रिप्ट का इस्तेमाल करें. Pixel 5 (Redfin) डिवाइस के लिए, ऑडियो नीति की V6 कॉन्फ़िगरेशन फ़ाइल को V7 वर्शन में बदलने के लिए, यह कमांड देखें:

hardware/interfaces/audio/7.0/config/update_audio_policy_config.sh \
device/google/redfin/audio/audio_policy_configuration.xml 6.0

डेटा टाइप

हमने डुप्लीकेट परिभाषाओं को कम करने के लिए, V7 में कुछ डेटा स्ट्रक्चर को फिर से तय किया है. डेटा आइटम के दोहराए गए टपल को फिर से इस्तेमाल किए जा सकने वाले स्ट्रक्चर में एक साथ ग्रुप किया जाता है. ये डेटा स्ट्रक्चर, सेफ़ यूनियन जैसी नई HIDL सुविधाओं का इस्तेमाल करते हैं.

उदाहरण के लिए, V6 और उससे पहले के वर्शन में, HIDL इंटरफ़ेस और टाइप में अक्सर <format, sampling rate, channel mask> के तीन बार इस्तेमाल किया जाता है. इस गड़बड़ी को ठीक करने के लिए, V7 में AudioConfigBaseडेटा टाइप और अन्य डेटा टाइप को इस तरह से तय किया गया है:

AudioConfigBase := <format, sampling rate, channel mask>
AudioConfigBaseOptional := <[fmt], [sampl. rate], [chan. mask]>

AudioConfig, AudioOffloadInfo, AudioPortConfig ने इस्तेमाल किया
AudioProfile := <format, {sampling rates}, {channel masks}>

AudioPort/PortConfig में मौजूद अलग-अलग कलेक्शन को बदलता है
AudioPortExtendedInfo := device | mix | session

AudioPort/PortConfig में यूनियन की जगह लेता है

वेंडर टैग

डिवाइस टाइप और फ़ॉर्मैट के अलावा, वेंडर ऑडियो ट्रैक के मेटाडेटा के लिए कस्टम टैग जोड़ सकते हैं.

ट्रैक के मेटाडेटा को चलाने और रिकॉर्ड करने के लिए, वेंडर अपने टैग पास कर सकते हैं. इन टैग का इस्तेमाल, ऐप्लिकेशन से HAL तक ऑडियो I/O स्ट्रीम में एट्रिब्यूट जोड़ने के लिए किया जाता है.

यहां दिए गए उदाहरण में दिखाए गए तरीके से, प्लेलिस्ट में शामिल ट्रैक के मेटाडेटा के लिए वेंडर टैग जोड़े जाते हैं:

struct PlaybackTrackMetadata {
…
    /** Tags from AudioTrack audio attributes */
    vec<AudioTag> tags;
};

RecordTrackMetadata स्ट्रक्चर को रिकॉर्डिंग ट्रैक के मेटाडेटा के लिए खास टैग जोड़कर, इसी तरह लागू किया जाता है.

वेंडर एक्सटेंशन के लिए नेमस्पेस

HAL V7 से, वेंडर एक्सटेंशन के लिए एक अतिरिक्त {vendor} प्रीफ़िक्स की ज़रूरत होती है. यह प्रीफ़िक्स, V6 में ज़रूरी नहीं है. {vendor} प्रीफ़िक्स मान्य होने के लिए, इसमें अक्षर और अंक मिलाकर तीन या इससे ज़्यादा वर्ण होने चाहिए.

V7 में इस फ़ॉर्मैट का इस्तेमाल करें:

VX_{vendor}_{letters/numbers}

यहां V7 वेंडर एक्सटेंशन के मान्य वर्शन के कुछ उदाहरण दिए गए हैं:

VX_GOOGLE_VR
VX_QCI_AMBIENT_MIC

वर्शन की जानकारी

नीचे दी गई टेबल में, हर Android रिलीज़ के लिए HAL वर्शन नंबर की सूची दी गई है:

Android वर्शन	HIDL HAL वर्शन
Android 13	7.1
Android 12	7.0
Android 11	6.0
Android 10	5.0
Android 9	4.0
Android 8	2.0