प्राथमिकता व्युत्क्रमण से बचें

यह लेख बताता है कि Android का ऑडियो सिस्टम इंटरनेट पर प्राथमिकता में बदलाव, और उन तकनीकों को हाइलाइट करता है जिनका आप भी इस्तेमाल कर सकते हैं.

ये तकनीकें, बेहतर परफ़ॉर्मेंस वाले डेवलपर के लिए काम की हो सकती हैं ऑडियो ऐप्लिकेशन, OEM, और SoC की सेवा देने वाली कंपनियां, जो ऑडियो का इस्तेमाल करती हैं हैल. कृपया ध्यान दें कि इन तकनीकों को लागू करना तकनीकी समस्याओं या दूसरी गड़बड़ियों से बचाने की गारंटी दी जाती है. खास तौर पर, का इस्तेमाल ऑडियो के अलावा कहीं और किया जा सकता है. जांच के नतीजे अलग-अलग हो सकते हैं और आपको खुद जांच करनी चाहिए आकलन और टेस्टिंग.

बैकग्राउंड

Android AudioFlinger ऑडियो सर्वर और AudioTrack/AudioRecord इंतज़ार के समय को कम करने के लिए, क्लाइंट लागू करने की प्रक्रिया को फिर से संग्रहित किया जा रहा है. यह काम Android 4.1 में शुरू हुआ और अन्य सुधारों के साथ जारी रहा 4.2, 4.3, 4.4, और 5.0 में.

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

प्राथमिकता व्युत्क्रमण

प्राथमिकता इन्वर्सेशन रियल-टाइम सिस्टम का एक क्लासिक फ़ेलियर मोड है, जहां ज़्यादा प्राथमिकता वाले टास्क को बिना किसी तय समय के इंतज़ार करने के लिए ब्लॉक कर दिया जाता है करने के लिए एक आसान तरीका है, जैसे कि ( राज्य) a म्यूटेक्स.

ऑडियो सिस्टम में, प्राथमिकता बदलने की सुविधा आम तौर पर ग्लिच (क्लिक करें, पॉप करें, ड्रॉप-आउट करें), दोहराया गया ऑडियो जब सर्कुलर बफ़र का इस्तेमाल किया जाता है या किसी निर्देश का जवाब देने में देरी होती है.

प्राथमिकता में बदलाव करने का एक आम तरीका, ऑडियो बफ़र का साइज़ बढ़ाना है. हालांकि, इस तरीके से इंतज़ार का समय बढ़ जाता है और समस्या कम हो जाती है उन्हें हल करने की ज़रूरत नहीं है. प्राथमिकता को समझना और रोकना बेहतर है डालें, जैसा कि नीचे दिखाया गया है.

Android ऑडियो को लागू करने में, प्राथमिकता में बदलाव करने की सुविधा सबसे इन जगहों पर होने की संभावना ज़्यादा होती है. इसलिए, आपको यहां अपना पूरा ध्यान देना चाहिए:

  • AudioFlinger में सामान्य मिक्सर थ्रेड और फ़ास्ट मिक्सर थ्रेड के बीच
  • तेज़ AudioTrack और फ़ास्ट मिक्सर थ्रेड (उन दोनों को ज़्यादा प्राथमिकता दी गई है, लेकिन यह थोड़ा-बहुत ज़रूरी है अलग-अलग प्राथमिकताएं)
  • तेज़ AudioRecord के लिए ऐप्लिकेशन कॉलबैक थ्रेड के बीच फ़ास्ट कैप्चर थ्रेड (पिछले से मिलता-जुलता)
  • को लागू करने के लिए, ऑडियो हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) के अंदर जाएं. जैसे, टेलीफ़ोनी या इको रद्द करने के लिए
  • कर्नेल में ऑडियो ड्राइवर के अंदर
  • AudioTrack या AudioRecord कॉलबैक थ्रेड और अन्य ऐप्लिकेशन थ्रेड के बीच (यह हमारे कंट्रोल में नहीं है)

सामान्य समाधान

सामान्य समाधानों में ये शामिल हैं:

  • रुकावटें बंद कर रही हूँ
  • प्रायॉरिटी इनहेरिटेंस म्यूटेक्स

Linux उपयोगकर्ता स्पेस में रुकावटें बंद करने की सुविधा बंद नहीं की जा सकती. ऐसा करने के लिए सिमेट्रिक मल्टी-प्रोसेसर (SMP) के लिए काम नहीं करता.

प्राथमिकता इनहेरिटेंस फ़्यूटेक्स (तेज़ यूज़र-स्पेस म्यूटेक्स) ऑडियो सिस्टम में इस्तेमाल नहीं किए जाते, क्योंकि वे भारी होते हैं, क्योंकि वे भरोसेमंद क्लाइंट पर निर्भर हैं.

Android की इस्तेमाल की गई तकनीकें

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

हम यह भी इस्तेमाल करते हैं ऐटॉमिक ऑपरेशन जैसे:

  • ज़्यादा
  • बिट के अनुसार "या"
  • बिट के अनुसार "और"

इन सभी विकल्पों में पिछले वैल्यू की जानकारी दी गई है. साथ ही, ज़रूरी शर्तों को पूरा करने के लिए, एसएमपी की रुकावटें. इसका नुकसान यह है कि उन्हें लगातार कई बार कोशिश करने की ज़रूरत पड़ सकती है. असल में, हमने पाया है कि यह कोशिश कोई समस्या नहीं है.

ध्यान दें: ऐटॉमिक ऑपरेशन और मेमोरी से जुड़ी सीमाओं के साथ उनके इंटरैक्शन गलत तरीके से समझे जाते हैं और गलत तरीके से इस्तेमाल किए जाते हैं. हम इन तरीकों को यहां पूरा पढ़ें. हालांकि, हमारा सुझाव है कि आप यह लेख भी पढ़ें Android के लिए SMP Primer देखें.

ऊपर दिए गए ज़्यादातर टूल अब भी मौजूद हैं और हम उनका इस्तेमाल करते हैं. हाल ही में इन तकनीकों को शामिल किया:

  • ब्लॉक न करने वाले सिंगल-रीडर वाले सिंगल-राइटर का इस्तेमाल करें एफ़आईएफ़ओ की सूचियां डेटा के लिए.
  • इसे आज़माएँ कॉपी करें राज्य के बजाय शेयर करें उच्च और उच्च स्तर के बीच की स्थिति कम प्राथमिकता वाले मॉड्यूल.
  • जब राज्य को शेयर करने की ज़रूरत हो, तो राज्य को ज़्यादा से ज़्यादा साइज़ शब्द जिसे एक बस की कार्रवाई से, अपने-आप ऐक्सेस किया जा सकता है वह भी बिना प्रयास करे.
  • कई शब्दों वाली मुश्किल स्थिति के लिए, राज्य की सूची का इस्तेमाल करें. राज्यों की सूची मूल रूप से बस एक ब्लॉक करने वाला सिंगल-रीडर एफ़आईएफ़ओ है सूची का इस्तेमाल डेटा के बजाय स्थिति के लिए किया जाता है, लेकिन लेखक छोटा हो जाता है एक ही बार में धक्का देते हैं.
  • इन बातों पर ध्यान दें मेमोरी से जुड़ी समस्याएँ किया जा सकता है.
  • भरोसेमंद हों, लेकिन पुष्टि करें. शेयर करते समय राज्य के बीच होता है, लेकिन यह मान लिया जाए कि राज्य की बनावट सही है. उदाहरण के लिए, देखें कि इंडेक्स सीमाओं के अंदर होते हैं. अलग-अलग थ्रेड के लिए, पुष्टि करने की यह प्रक्रिया ज़रूरी नहीं है एक ही प्रक्रिया में, आपसी भरोसा करने वाली प्रक्रियाओं के बीच (जिसमें आम तौर पर एक ही यूआईडी होता है). शेयर करने के लिए भी यह ज़रूरी नहीं है डेटा जैसे, PCM ऑडियो, जिसमें गड़बड़ी का कोई असर न पड़ता हो.

ब्लॉक न करने वाले एल्गोरिदम

ब्लॉक न करने वाले एल्गोरिदम हाल ही में किए गए अध्ययन का विषय रहे हैं. हालांकि, एक ही किताब में लिखने वाले लोगों की सूची में मौजूद एफ़आईएफ़ओ की सूची को छोड़कर, हमने उन्हें जटिल और गड़बड़ियों की संभावना वाली पाया.

Android 4.2 से, आप इन देशों/इलाकों में, एक व्यक्ति/लेखिका के लिए क्लास दी जाती हैं:

  • फ़्रेमवर्क/Av/include/मीडिया/nbaio/
  • फ़्रेमवर्क/Av/मीडिया/libnbaio/
  • फ़्रेमवर्क/एवी/सेवाएं/ऑडियोफ़्लिंगर/स्टेटकक्यू*

इन्हें खास तौर पर AudioFlinger के लिए डिज़ाइन किया गया था और अलग-अलग कामों के लिए इस्तेमाल की जाती है. ब्लॉक न करने वाले एल्गोरिदम, डीबग करना मुश्किल. इस कोड को मॉडल के तौर पर देखा जा सकता है. हालांकि, इस बात की कोई गारंटी नहीं है कि क्लास में होने वाली गड़बड़ियां हो सकती हैं. इसलिए, इस बात की कोई गारंटी नहीं है कि अन्य कामों के लिए सही है.

डेवलपर के लिए, कुछ नमूना OpenSL ES ऐप्लिकेशन कोड यहां अपडेट किए जाने चाहिए ब्लॉक न करने वाले एल्गोरिदम का इस्तेमाल करें या बिना Android वाली ओपन सोर्स लाइब्रेरी का रेफ़रंस दें.

हमने एक उदाहरण पब्लिश किया है, जिसमें ब्लॉक न करने वाले एफ़आईएफ़ओ को लागू करने का एक उदाहरण दिया गया है. इसे खास तौर पर ऐप्लिकेशन कोड. प्लैटफ़ॉर्म सोर्स डायरेक्ट्री में मौजूद इन फ़ाइलों को देखें frameworks/av/audio_utils:

टूल

हमारी जानकारी के हिसाब से, ऐसा कोई स्वचालित टूल नहीं है जो और खासकर सबसे पहले, उन शब्दों को शामिल न करें. कुछ सूचनाएं मिल रही हैं स्थैतिक कोड विश्लेषण टूल आपकी प्राथमिकता और पहचान अगर पूरे कोड बेस को ऐक्सेस किया जा सकता है, तो कोड में बदलाव भी नहीं किया जा सकता. बेशक, अगर आर्बिट्रेरी यूज़र कोड शामिल है (जैसा कि यह ऐप्लिकेशन के लिए यहां है) या एक बड़ा कोड बेस है (जैसे कि Linux कर्नेल और डिवाइस ड्राइवर के लिए), स्थैतिक विश्लेषण अव्यावहारिक हो सकते हैं. सबसे ज़रूरी बात है कि कोड को ध्यान से पढ़ें और पूरे कोड को अच्छी तरह से समझें किस तरह इस्तेमाल करते हैं. ऐसे टूल सिस्ट ट्रेस और ps -t -p प्राथमिकता में व्युत्क्रम होने के बाद उन्हें देखने के लिए उपयोगी होते हैं, लेकिन तो आपको इस बारे में नहीं बताना चाहिए.

आखिरी शब्द

यह चर्चा पूरी होने के बाद, म्यूटेक्स से न डरें. म्यूटेक्स जब सही तरीके से उपयोग और लागू किए गए हों, तो सामान्य उपयोग के लिए आपके दोस्त हों बेहद ज़रूरी हैं. हालांकि, ज़्यादा से ज़्यादा कम प्राथमिकता वाले टास्क और टाइम सेंसिटिव सिस्टम में म्यूटेक्स परेशानी हो सकती है.