यह आलेख बताता है कि कैसे Android का ऑडियो सिस्टम प्राथमिकता उलटने से बचने का प्रयास करता है, और उन तकनीकों पर प्रकाश डालता है जिनका आप भी उपयोग कर सकते हैं।
ये तकनीक उच्च-प्रदर्शन ऑडियो ऐप, ओईएम और एसओसी प्रदाताओं के डेवलपर्स के लिए उपयोगी हो सकती हैं जो ऑडियो एचएएल को लागू कर रहे हैं। कृपया ध्यान दें कि इन तकनीकों को लागू करने से गड़बड़ियों या अन्य विफलताओं को रोकने की गारंटी नहीं है, खासकर अगर ऑडियो संदर्भ के बाहर उपयोग किया जाता है। आपके परिणाम भिन्न हो सकते हैं, और आपको अपना मूल्यांकन और परीक्षण स्वयं करना चाहिए।
पार्श्वभूमि
विलंबता को कम करने के लिए Android AudioFlinger ऑडियो सर्वर और AudioTrack/AudioRecord क्लाइंट कार्यान्वयन को फिर से तैयार किया जा रहा है। यह कार्य Android 4.1 में शुरू हुआ और 4.2, 4.3, 4.4 और 5.0 में और सुधार के साथ जारी रहा।
इस कम विलंबता को प्राप्त करने के लिए, पूरे सिस्टम में कई बदलावों की आवश्यकता थी। एक महत्वपूर्ण परिवर्तन सीपीयू संसाधनों को अधिक पूर्वानुमानित शेड्यूलिंग नीति के साथ समय-महत्वपूर्ण थ्रेड्स को असाइन करना है। विश्वसनीय शेड्यूलिंग ऑडियो बफर आकार और गणना को कम करने की अनुमति देता है जबकि अभी भी अंडररन और ओवररन से बचा जाता है।
प्राथमिकता उलटा
प्रायोरिटी इनवर्जन रियल-टाइम सिस्टम का एक क्लासिक विफलता मोड है, जहां एक उच्च-प्राथमिकता वाले कार्य को एक अनबाउंड समय के लिए अवरुद्ध कर दिया जाता है, जो कि एक म्यूटेक्स जैसे संसाधन (साझा राज्य द्वारा संरक्षित) को जारी करने के लिए कम-प्राथमिकता वाले कार्य की प्रतीक्षा कर रहा है।
एक ऑडियो सिस्टम में, प्राथमिकता उलटा आम तौर पर एक गड़बड़ (क्लिक, पॉप, ड्रॉपआउट) के रूप में प्रकट होता है, जब सर्कुलर बफर का उपयोग किया जाता है, या कमांड के जवाब में देरी होने पर दोहराए गए ऑडियो ।
प्राथमिकता उलटाने के लिए एक सामान्य समाधान ऑडियो बफर आकार बढ़ाना है। हालाँकि, यह विधि विलंबता को बढ़ाती है और समस्या को हल करने के बजाय केवल छुपाती है। प्राथमिकता व्युत्क्रम को समझना और रोकना बेहतर है, जैसा कि नीचे देखा गया है।
एंड्रॉइड ऑडियो कार्यान्वयन में, इन जगहों पर प्राथमिकता उलटा होने की सबसे अधिक संभावना है। और इसलिए आपको अपना ध्यान यहां केंद्रित करना चाहिए:
- AudioFlinger में सामान्य मिक्सर थ्रेड और तेज़ मिक्सर थ्रेड के बीच
- तेज़ ऑडियोट्रैक और तेज़ मिक्सर थ्रेड के लिए एप्लिकेशन कॉलबैक थ्रेड के बीच (उन दोनों की प्राथमिकता बढ़ी है, लेकिन थोड़ी अलग प्राथमिकताएं हैं)
- तेज़ AudioRecord और तेज़ कैप्चर थ्रेड के लिए एप्लिकेशन कॉलबैक थ्रेड के बीच (पिछले के समान)
- ऑडियो हार्डवेयर एब्स्ट्रैक्शन लेयर (HAL) कार्यान्वयन के भीतर, उदाहरण के लिए टेलीफोनी या इको रद्दीकरण के लिए
- कर्नेल में ऑडियो ड्राइवर के भीतर
- AudioTrack या AudioRecord कॉलबैक थ्रेड और अन्य ऐप थ्रेड्स के बीच (यह हमारे नियंत्रण से बाहर है)
सामान्य समाधान
विशिष्ट समाधानों में शामिल हैं:
- व्यवधान अक्षम करना
- प्राथमिकता विरासत म्यूटेक्स
लिनक्स उपयोगकर्ता स्थान में इंटरप्ट को अक्षम करना संभव नहीं है, और सममित मल्टी-प्रोसेसर (एसएमपी) के लिए काम नहीं करता है।
ऑडियो सिस्टम में प्रायोरिटी इनहेरिटेंस फ़्यूटेक्स (तेज़ उपयोगकर्ता-स्पेस म्यूटेक्स) का उपयोग नहीं किया जाता है क्योंकि वे अपेक्षाकृत भारी होते हैं, और क्योंकि वे एक विश्वसनीय क्लाइंट पर निर्भर होते हैं।
Android द्वारा उपयोग की जाने वाली तकनीक
प्रयोग "प्रयास लॉक" और टाइमआउट के साथ लॉक के साथ शुरू हुए। ये म्यूटेक्स लॉक ऑपरेशन के नॉन-ब्लॉकिंग और बाउंडेड ब्लॉकिंग वेरिएंट हैं। टाइमआउट के साथ लॉक और लॉक का प्रयास करें काफी अच्छा काम किया लेकिन कुछ अस्पष्ट विफलता मोड के लिए अतिसंवेदनशील थे: सर्वर को साझा स्थिति तक पहुंचने में सक्षम होने की गारंटी नहीं थी यदि क्लाइंट व्यस्त हो, और संचयी टाइमआउट बहुत लंबा हो सकता है यदि असंबंधित तालों का एक लंबा क्रम था जो सभी समय समाप्त हो गया था।
हम परमाणु संचालन का भी उपयोग करते हैं जैसे:
- वेतन वृद्धि
- बिटवाइज़ "या"
- बिटवाइज़ "और"
ये सभी पिछले मान लौटाते हैं और इसमें आवश्यक एसएमपी बाधाएं शामिल होती हैं। नुकसान यह है कि उन्हें असीमित पुनर्प्रयासों की आवश्यकता हो सकती है। व्यवहार में, हमने पाया है कि पुनर्प्रयास कोई समस्या नहीं है।
नोट: परमाणु संचालन और स्मृति बाधाओं के साथ उनकी बातचीत को बेहद गलत समझा जाता है और गलत तरीके से उपयोग किया जाता है। हम इन विधियों को यहाँ पूर्णता के लिए शामिल करते हैं लेकिन अनुशंसा करते हैं कि आप अधिक जानकारी के लिए Android के लिए SMP प्राइमर लेख भी पढ़ें।
हमारे पास अभी भी उपरोक्त अधिकांश उपकरण हैं और उनका उपयोग करते हैं, और हाल ही में इन तकनीकों को जोड़ा है:
- डेटा के लिए गैर-अवरुद्ध एकल-पाठक एकल-लेखक FIFO कतारों का उपयोग करें।
- उच्च और निम्न-प्राथमिकता वाले मॉड्यूल के बीच राज्य साझा करने के बजाय राज्य की प्रतिलिपि बनाने का प्रयास करें।
- जब राज्य को साझा करने की आवश्यकता होती है, तो राज्य को अधिकतम-आकार के शब्द तक सीमित करें, जिसे बिना पुन: प्रयास के एक-बस संचालन में परमाणु रूप से पहुँचा जा सकता है।
- जटिल बहु-शब्द स्थिति के लिए, राज्य कतार का उपयोग करें। एक राज्य कतार मूल रूप से केवल एक गैर-अवरुद्ध एकल-पाठक एकल-लेखक फीफो कतार है जो डेटा के बजाय राज्य के लिए उपयोग की जाती है, सिवाय इसके कि लेखक एक ही धक्का में आसन्न धक्का को ध्वस्त कर देता है।
- एसएमपी शुद्धता के लिए स्मृति बाधाओं पर ध्यान दें।
- विश्वास करें, लेकिन सत्यापित करें । प्रक्रियाओं के बीच राज्य साझा करते समय, यह न मानें कि राज्य अच्छी तरह से गठित है। उदाहरण के लिए, जांचें कि सूचकांक सीमा के भीतर हैं। एक ही प्रक्रिया में थ्रेड्स के बीच, आपसी भरोसेमंद प्रक्रियाओं (जिसमें आमतौर पर एक ही यूआईडी होता है) के बीच इस सत्यापन की आवश्यकता नहीं होती है। पीसीएम ऑडियो जैसे साझा डेटा के लिए भी यह अनावश्यक है जहां भ्रष्टाचार अप्रासंगिक है।
गैर-अवरुद्ध एल्गोरिदम
गैर-अवरुद्ध एल्गोरिदम हाल के अध्ययन का विषय रहा है। लेकिन एकल-पाठक एकल-लेखक FIFO कतारों के अपवाद के साथ, हमने उन्हें जटिल और त्रुटि-प्रवण पाया है।
Android 4.2 से शुरू होकर, आप इन स्थानों पर हमारे गैर-अवरुद्ध, एकल-पाठक/लेखक वर्ग पा सकते हैं:
- चौखटे/एवी/शामिल/मीडिया/एनबीएओ/
- चौखटे/एवी/मीडिया/libnbaio/
- फ्रेमवर्क/एवी/सेवाएं/ऑडियोफ्लिंगर/स्टेट क्यू*
ये विशेष रूप से AudioFlinger के लिए डिज़ाइन किए गए थे और सामान्य प्रयोजन के नहीं हैं। गैर-अवरुद्ध एल्गोरिदम डीबग करना मुश्किल होने के लिए कुख्यात हैं। आप इस कोड को एक मॉडल के रूप में देख सकते हैं। लेकिन सावधान रहें कि बग हो सकते हैं, और कक्षाओं को अन्य उद्देश्यों के लिए उपयुक्त होने की गारंटी नहीं है।
डेवलपर्स के लिए, कुछ नमूना ओपनएसएल ईएस एप्लिकेशन कोड को गैर-अवरुद्ध एल्गोरिदम का उपयोग करने या गैर-एंड्रॉइड ओपन सोर्स लाइब्रेरी का संदर्भ देने के लिए अद्यतन किया जाना चाहिए।
हमने एक उदाहरण गैर-अवरुद्ध फीफो कार्यान्वयन प्रकाशित किया है जो विशेष रूप से एप्लिकेशन कोड के लिए डिज़ाइन किया गया है। प्लेटफ़ॉर्म स्रोत निर्देशिका frameworks/av/audio_utils में स्थित इन फ़ाइलों को देखें:
औजार
हमारे सर्वोत्तम ज्ञान के लिए, प्राथमिकता उलटा खोजने के लिए कोई स्वचालित उपकरण नहीं हैं, खासकर ऐसा होने से पहले। कुछ शोध स्थिर कोड विश्लेषण उपकरण प्राथमिकता व्युत्क्रम खोजने में सक्षम हैं यदि पूरे कोडबेस तक पहुंचने में सक्षम हैं। बेशक, यदि मनमाना उपयोगकर्ता कोड शामिल है (जैसा कि यह एप्लिकेशन के लिए यहां है) या एक बड़ा कोडबेस (लिनक्स कर्नेल और डिवाइस ड्राइवरों के लिए) है, तो स्थिर विश्लेषण अव्यावहारिक हो सकता है। सबसे महत्वपूर्ण बात यह है कि कोड को बहुत ध्यान से पढ़ें और पूरे सिस्टम और इंटरैक्शन पर एक अच्छी समझ प्राप्त करें। सिस्ट्रेस और ps -t -p जैसे उपकरण प्राथमिकता उलटा होने के बाद देखने के लिए उपयोगी होते हैं, लेकिन आपको पहले से नहीं बताते हैं।
एक अंतिम शब्द
इस सारी चर्चा के बाद, म्यूटेक्स से डरो मत। सामान्य उपयोग के लिए म्यूटेक्स आपके मित्र हैं, जब सामान्य गैर-समय-महत्वपूर्ण उपयोग मामलों में सही ढंग से उपयोग और कार्यान्वित किया जाता है। लेकिन उच्च और निम्न-प्राथमिकता वाले कार्यों के बीच और समय के प्रति संवेदनशील सिस्टम में म्यूटेक्स के कारण परेशानी होने की संभावना अधिक होती है।