HIDL ऑडियो एचएएल

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

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

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

ऑडियो नीति और ऑडियो इफ़ेक्ट की एक्सएमएल कॉन्फ़िगरेशन फ़ाइलों को Audio HIDL 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 से ऑडियो भेजने या पाने के लिए किया जाता है.

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

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

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

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

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

कॉमन एचएएल

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

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

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

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

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

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

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

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

एनोटेशन

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

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

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

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

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

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

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

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

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

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

1. AudioFormat की ईनम वैल्यू को libaudiohal में स्ट्रिंग वैल्यू में बदला जाता है और इसे एचएएल को पास किया जाता है.
2. 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 वर्शन नंबर की सूची दी गई है: