आईओएस में कम विलंबता ऑडियो प्रोग्रामिंग

लेख में आईओएस में ध्वनि के साथ काम करने के लिए निम्न-स्तरीय एपीआई की सुविधाओं पर चर्चा की जाएगी, जो Viber विकसित करते समय सामना किए गए थे। यह सैंपलिंग फ़्रीक्वेंसी बदलते समय हार्डवेयर बफर के आकार और AudioUnit के व्यवहार को चुनने के बारे में होगा।

आईओएस में ध्वनि के साथ सॉफ्टवेयर काम के लिए, Apple 4 एपीआई के समूह प्रदान करता है, जिनमें से प्रत्येक को विशिष्ट वर्ग के कार्यों को हल करने के लिए डिज़ाइन किया गया है:

• AVFoundation आपको प्लेटफ़ॉर्म द्वारा प्रदान किए गए कुछ ऑडियो कोडेक्स के हार्डवेयर या सॉफ़्टवेयर कार्यान्वयन का उपयोग करने की क्षमता के साथ फ़ाइलों और बफ़र्स को स्मृति में चलाने और रिकॉर्ड करने की अनुमति देता है। प्लेबैक और प्लेबैक की कम विलंबता के लिए कोई सख्त आवश्यकता नहीं होने पर इसका उपयोग करने की सिफारिश की जाती है।
• ओपन एपीआई तीन आयामी ध्वनि और ध्वनि प्रभाव के उपयोग के साथ-साथ प्रस्तुत करने के लिए अभिप्रेत है। यह मुख्य रूप से खेलों में उपयोग किया जाता है। कम प्लेबैक देरी प्रदान करता है, लेकिन ध्वनि रिकॉर्ड करने की क्षमता प्रदान नहीं करता है।
• AudioQueue रिकॉर्डिंग और मंच द्वारा प्रदान किए गए कोडेक्स का उपयोग करने की क्षमता के साथ ऑडियो स्ट्रीम खेलने के लिए एक बुनियादी एपीआई है। इस API का उपयोग करके, आपको न्यूनतम विलंब नहीं मिल सकता है, लेकिन इसका उपयोग करना बेहद सरल है।
• और अंत में, AudioUnit , ऑडियो स्ट्रीम के साथ काम करने के लिए एक शक्तिशाली और समृद्ध एपीआई। आईओएस पर मैक ओएस एक्स की तुलना में, प्रोग्रामर पूरी तरह से सुलभ नहीं है, लेकिन संभव के रूप में हार्डवेयर के करीब रिकॉर्डिंग और ध्वनि के लिए सबसे उपयुक्त है।

AudioUnit

आधिकारिक दस्तावेज़ में उदाहरण सहित ऑडियोयूनेट के आरंभ और बुनियादी उपयोग के बारे में काफी कुछ लिखा गया है। आइए इसके कॉन्फ़िगरेशन और उपयोग की बिल्कुल तुच्छ विशेषताओं पर विचार न करें। जितना संभव हो उतना हार्डवेयर के साथ ध्वनि के साथ बातचीत के लिए, RemoteIO और VoiceProcessingIO मॉड्यूल जिम्मेदार हैं। VoiceProcessingIO आवाज की गुणवत्ता और स्वचालित सिग्नल स्तर सुधार (AGC) में सुधार करने के लिए OS स्तर पर अतिरिक्त ध्वनि प्रसंस्करण को नियंत्रित करने की क्षमता RemoteIO को जोड़ता है। प्रोग्रामर के दृष्टिकोण से, इन दोनों मॉड्यूल में एक "इनपुट" और एक "आउटपुट" है, जिसमें 2 बसें जुड़ी हुई हैं।

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

OSStatus AURenderCallback(void * inRefCon, AudioUnitRenderActionFlags * ioActionFlags, const AudioTimeStamp * inTimeStamp, Int32 inBusNumber, UInt32 inNumberFrames, AudioBufferList * ioData); 

InputCallback तब कहा जाता है जब मॉड्यूल हमें माइक्रोफोन से रिकॉर्ड किए गए डेटा का एक बफर प्रदान करने के लिए तैयार होता है। इस डेटा को एप्लिकेशन में लाने के लिए, आपको इस कॉलबैक में AudioUnitRender फ़ंक्शन को कॉल करना होगा। RenderCallback तब कहा जाता है जब मॉड्यूल प्लेबैक डेटा के लिए आवेदन को ioData बफर को लिखने के लिए कहता है। इन कॉलबैक को आंतरिक AudioUnit स्ट्रीम के संदर्भ में कहा जाता है और इसे जल्द से जल्द निष्पादित करना चाहिए। आदर्श रूप से, उनका काम केवल तैयार किए गए डेटा बफ़र्स को कॉपी करने तक सीमित होना चाहिए। यह स्ट्रीम सिंक्रनाइज़ेशन के संदर्भ में ऑडियो सिग्नल प्रोसेसिंग के संगठन में अतिरिक्त कठिनाइयों का परिचय देता है। बफ़र्स के अलावा, फॉर्म में इन कॉलबैक पर एक टाइमस्टैम्प भेजा जाता है:

 struct AudioTimeStamp { Float64 mSampleTime; //     UInt64 mHostTime; //      //       // ... UInt32 mFlags; //       }; 

रिकॉर्डिंग और प्लेबैक के दौरान लापता नमूनों का पता लगाने के लिए इस टाइमस्टैम्प का उपयोग (और किया जाना चाहिए) किया जाना चाहिए। नमूनों के नुकसान के मुख्य कारण:

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

हार्डवेयर बफर आकार

आदर्श मामले में, रिकॉर्डिंग ध्वनि में न्यूनतम विलंब प्राप्त करने के लिए, कोई मध्यवर्ती बफरिंग नहीं है। हालांकि, वास्तविक दुनिया में, हार्डवेयर और सॉफ्टवेयर एकल नमूनों के बजाय अनुक्रमिक नमूनों के समूहों के साथ काम करने के लिए अधिक अनुकूलित हैं। उसी समय, iOS हार्डवेयर बफ़र के आकार को समायोजित करने की क्षमता प्रदान करता है। ऑडियो सत्र PreferredHardwareIOBufferDuration की संपत्ति आपको सेकंड में आवश्यक बफर अवधि का अनुरोध करने की अनुमति देती है, और CurrentHardwareIOBufferDuration - वास्तविक प्राप्त करने के लिए। संभावित अवधि वर्तमान नमूना दर पर निर्भर करती है। उदाहरण के लिए, डिफ़ॉल्ट रूप से, अंतर्निहित स्पीकर के माध्यम से खेलते समय और अंतर्निहित माइक्रोफ़ोन के माध्यम से रिकॉर्डिंग करने पर, उपकरण 44100Hz की नमूना आवृत्ति के साथ काम करेगा। ऑडियो सबसिस्टम द्वारा उपयोग किया जाने वाला न्यूनतम बफर 256 बाइट्स है, आकार आमतौर पर दो की शक्ति के बराबर होता है (मान प्रयोगात्मक रूप से प्राप्त किए जाते हैं और प्रलेखन में प्रकट नहीं होते हैं)। इसलिए, एक बफर की अवधि हो सकती है:
256/44100 = 5.805 मी
512/44100 = 11.61ms
1024/44100 = 23.22 मी
यदि आप 16000Hz के नमूने की आवृत्ति के साथ एक ब्लूटूथ हेडसेट का उपयोग करते हैं, तो हार्डवेयर बफर का आकार निम्न हो सकता है:
256/16000 = 16 मी
512/16000 = 32 मी
1024/16000 = 64 मी

हार्डवेयर बफ़र की अवधि न केवल विलंब को प्रभावित करती है, बल्कि उन नमूनों की संख्या भी होती है जो ऑडियोयूनेट हर बार एप्लिकेशन के साथ कॉलबैक को कॉल करता है। यदि नमूना आवृत्ति AudioUnit के इनपुट और आउटपुट पर मेल खाती है, तो हार्डवेयर में अवधि के बराबर एक बफर प्रेषित किया जाएगा और कॉलबैक में अनुरोध किया जाएगा, और कॉलबैक को नियमित अंतराल पर कॉल किया जाएगा। तदनुसार, यदि एप्लिकेशन एल्गोरिदम को प्रत्येक 10ms के अनुक्रम के साथ काम करने के लिए डिज़ाइन किया गया है, तो आवेदन पक्ष पर मध्यवर्ती बफरिंग किसी भी मामले में आवश्यक होगी, क्योंकि ऑडियोयूनेट को मनमाना अवधि के बफ़र्स के साथ काम करने के लिए कॉन्फ़िगर नहीं किया जा सकता है। हार्डवेयर बफर का आकार सबसे अच्छा प्रयोगात्मक रूप से चुना जाता है, विशिष्ट उपकरणों के प्रदर्शन को ध्यान में रखते हुए। घटने में विलंबता में सुधार होता है, लेकिन कॉलबैक को कॉल करते समय स्विचिंग फ्लो के ओवरहेड को जोड़ता है और सीपीयू लोड अधिक होने पर नमूनों को छोड़ने की संभावना बढ़ जाती है।

नमूनाकरण दर में परिवर्तन होने पर बफरिंग

वीओआईपी संचार के लिए अनुप्रयोगों में, यह हमेशा 16000Hz से ऊपर के नमूने की आवृत्ति के साथ ध्वनि को संसाधित करने के लिए समझ में नहीं आता है। इसके अलावा, हार्डवेयर नमूनाकरण दर को अनदेखा करना आसान है, क्योंकि यह ध्वनि स्रोत को स्विच करते समय किसी भी समय बदल सकता है। AudioUnit को कॉन्फ़िगर करके, आप AudioUnit के साथ डेटा का आदान-प्रदान करते समय ऑडियो स्ट्रीम का नमूना दर सेट कर सकते हैं। विचार करें कि यह निम्नलिखित उदाहरण में ध्वनि रिकॉर्डिंग के लिए कैसे काम करेगा:

 SampleRateHW = 44100 //    buffSizeHW = 1024 //    (1024 / 44100 = 23.22ms) mSampleRateAPP = 16000 //    buffSizeAPP = 1024 * 16000/44100 = 371.52 //     

रेज़मैपलिंग के बाद, आउटपुट एक पूर्णांक संख्या के नमूने होंगे, और आंशिक शेष को रेज़मैपलिंग फ़िल्टर गुणांक के रूप में संग्रहीत किया जाएगा। AudioUnit का व्यवहार iOS5 और iOS6 में काफी भिन्न है।

iOS5

IOS5 में, AudioUnit मॉड्यूल आकार में बफ़र्स का आदान-प्रदान करते हैं जो दो की शक्ति के गुणक हैं, इसलिए पहली कॉल के दौरान आवेदन को 256 नमूने (16ms @ 16kHz) प्राप्त होंगे। शेष 371-256 = 115 AudioUnit के अंदर रहेगा।


दूसरे कॉलबैक कॉल पर, एप्लिकेशन को फिर से 256 नमूनों का एक बफर प्राप्त होगा: इसमें डेटा का हिस्सा पिछले हार्डवेयर बफर से होगा, और नए से भाग।


तीसरी कॉल पर, रेज़मैपलिंग के बाद जमा हुआ बैलेंस आपको 512 नमूनों को तुरंत आवेदन में स्थानांतरित करने की अनुमति देगा।


फिर, फिर से, आवेदन 256 नमूने प्राप्त करता है।


इस प्रकार, जब रेज़मैपलिंग के साथ रिकॉर्डिंग की जाती है, तो नियमित अंतराल पर कॉलबैक कहा जाएगा, और इसे प्राप्त होने वाले बफर का आकार स्थिर नहीं होगा (लेकिन दो की शक्ति के बराबर)।

iOS6

IOS6 में, अनुप्रयोग और AudioUnit के बीच स्थानांतरित बफर के आकार पर प्रतिबंध हटा दिया गया था, इस प्रकार resampling के दौरान मध्यवर्ती बफरिंग को समाप्त कर दिया और, तदनुसार, देरी को कम किया। आवेदन को 371 और 372 नमूनों के बफ़र वैकल्पिक रूप से प्राप्त होंगे।

CoreAudio API को समझने योग्य और अच्छी तरह से प्रलेखित किया जाना कठिन है। कार्य की कई विशेषताओं को प्रयोगात्मक रूप से पहचाना जाना चाहिए, लेकिन आपको यह याद रखना होगा कि ओएस के विभिन्न संस्करणों में व्यवहार भिन्न हो सकता है। जो लोग Apple दस्तावेज़ीकरण के अलावा वास्तविक समय ऑडियो प्रोसेसिंग के विषय में रुचि रखते हैं, उनके लिए "iZotope iOS ऑडियो प्रोग्रामिंग गाइड" की सिफारिश की जा सकती है।